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