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

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

Re: Threadpool item mailboxes design problem

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Threadpool item mailboxes design problem Chris Rebert <clp2@rebertia.com> - 2013-04-14 19:32 -0700

#43596 — Re: Threadpool item mailboxes design problem

[Multipart message — attachments visible in raw view] — view raw

On Apr 14, 2013 4:27 PM, "Charles Hixson" <charleshixsn@earthlink.net>
wrote:
>
> What is the best approach to implementing actors that accept and post
messages (and have no other external contacts).

You might look at how some of the existing Python actor libraries are
implemented (perhaps one of these might even save you from reinventing the
wheel):

http://www.pykka.org/en/latest/
http://www.kamaelia.org/Docs/Axon/Axon.html
https://pypi.python.org/pypi/pulsar

Kinda old:
http://candygram.sourceforge.net/contents.html
http://osl.cs.uiuc.edu/parley/

> 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.
<snip>
> 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?)

My recollection is that the built-in collection types are threadsafe at
least to the limited extent that the operations exposed by their APIs (e.g.
dict.setdefault) are atomic.
Perhaps someone will be able to chime in with more details.

[toc] | [standalone]

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

csiph-web