Threadpool item mailboxes design problem
88888 Dihedral
dihedral88888 at googlemail.com
Sun Apr 14 22:41:39 EDT 2013
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?)
>
>
>
> --
>
> Charles Hixson
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?
More information about the Python-list
mailing list