Threadpool item mailboxes design problem

C

Charles Hixson

What is the best approach to implementing actors that accept and post
messages (and have no other external contacts).

So far what I've come up with is something like:
actors = {}
mailboxs = {}

Stuff actors with actor instances, mailboxes with multiprocessing.queue
instances. (Actors and mailboxes will have identical keys, which are
id#, but it's got to be a dict rather than a list, because too many are
rolled out to disk.) And I'm planning of having the actors running
simultaneously and continually in a threadpool that just loops through
the actors that are assigned to each thread of the pool.

This lets any actor post messages to the mailbox of any other actor that
it has the id of, and lets him read his own mail without
multi-processing clashes. But I'm quite uncertain that this is the best
way, because, if nothing else, it means that each mailbox needs to be
allocated large enough to handle the maximum amount of mail it could
possibly receive. (I suppose I could implement some sort of "wait
awhile and try again" method.) It would, however, be better if the
mailbox could be specific to the threadpool instance, so less space
would be wasted. Or if the queues could dynamically resize. Or if
there was a threadsafe dict. Or... But I don't know that any of these
are feasible. (I mean, yes, I could write all the mail to a database,
but is that a better answer, or even a good one?)
 
8

88888 Dihedral

Charles Hixsonæ–¼ 2013å¹´4月15日星期一UTC+8上åˆ7時12分11秒寫é“:
What is the best approach to implementing actors that accept and post

messages (and have no other external contacts).



So far what I've come up with is something like:

actors = {}

mailboxs = {}



Stuff actors with actor instances, mailboxes with multiprocessing.queue

instances. (Actors and mailboxes will have identical keys, which are

id#, but it's got to be a dict rather than a list, because too many are

rolled out to disk.) And I'm planning of having the actors running

simultaneously and continually in a threadpool that just loops through

the actors that are assigned to each thread of the pool.



This lets any actor post messages to the mailbox of any other actor that

it has the id of, and lets him read his own mail without

multi-processing clashes. But I'm quite uncertain that this is the best

way, because, if nothing else, it means that each mailbox needs to be

allocated large enough to handle the maximum amount of mail it could

possibly receive. (I suppose I could implement some sort of "wait

awhile and try again" method.) It would, however, be better if the

mailbox could be specific to the threadpool instance, so less space

would be wasted. Or if the queues could dynamically resize. Or if

there was a threadsafe dict. Or... But I don't know that any of these

are feasible. (I mean, yes, I could write all the mail to a database,

but is that a better answer, or even a good one?)

Actors can receive and response to messages to take actions
accordingly in time in one or more cores.

The timer is required and the message read/write operations
are required.

Do you want the actors to gain new methods to evolve
in the long run?
 
8

88888 Dihedral

Charles Hixsonæ–¼ 2013å¹´4月15日星期一UTC+8上åˆ7時12分11秒寫é“:
What is the best approach to implementing actors that accept and post

messages (and have no other external contacts).



So far what I've come up with is something like:

actors = {}

mailboxs = {}



Stuff actors with actor instances, mailboxes with multiprocessing.queue

instances. (Actors and mailboxes will have identical keys, which are

id#, but it's got to be a dict rather than a list, because too many are

rolled out to disk.) And I'm planning of having the actors running

simultaneously and continually in a threadpool that just loops through

the actors that are assigned to each thread of the pool.



This lets any actor post messages to the mailbox of any other actor that

it has the id of, and lets him read his own mail without

multi-processing clashes. But I'm quite uncertain that this is the best

way, because, if nothing else, it means that each mailbox needs to be

allocated large enough to handle the maximum amount of mail it could

possibly receive. (I suppose I could implement some sort of "wait

awhile and try again" method.) It would, however, be better if the

mailbox could be specific to the threadpool instance, so less space

would be wasted. Or if the queues could dynamically resize. Or if

there was a threadsafe dict. Or... But I don't know that any of these

are feasible. (I mean, yes, I could write all the mail to a database,

but is that a better answer, or even a good one?)

Actors can receive and response to messages to take actions
accordingly in time in one or more cores.

The timer is required and the message read/write operations
are required.

Do you want the actors to gain new methods to evolve
in the long run?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,821
Messages
2,569,747
Members
45,726
Latest member
RaleighAll

Latest Threads

Top