Threadpool item mailboxes design problem

[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?)

 

[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?

 

[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?