Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43586 > unrolled thread

Threadpool item mailboxes design problem

Back to article view | Back to comp.lang.python

Contents

  Threadpool item mailboxes design problem Charles Hixson <charleshixsn@earthlink.net> - 2013-04-14 16:12 -0700
    Re: Threadpool item mailboxes design problem 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-14 19:41 -0700
    Re: Threadpool item mailboxes design problem 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-14 19:41 -0700

#43586 — Threadpool item mailboxes design problem

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

[toc] | [next] | [standalone]

#43599

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?

[toc] | [prev] | [next] | [standalone]

#43600

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?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web