Sharing objects between processes

[Aaron Brady]

On Mar 9, 4:21 pm, ET <p... at 2drpg.org> wrote:
> On Mon, 2009-03-09 at 13:58 -0700, Aaron Brady wrote:
> > On Mar 9, 2:17 pm, ET <p... at 2drpg.org> wrote:
> > > On Mon, 2009-03-09 at 11:04 -0700, Aaron Brady wrote:
snip
> > Here's what we have to work with from you:
>
> > > > > > > The problem, as briefly as possible:
> > > > > > > I have three processes which need to safely read and update two objects.
>
> > Can they be subprocesses of eachother?  That is, can one master spawn
> > the others as you desire?  Can you have one process running, and
> > connect to it with sockets, pipes, (mailslots,) etc., and just give
> > and get the information to it?  Then, synch. is a lot easier.
>
> > Do you need MROW multiple-reader one-writer synchro., or can they all
> > go one at a time?  Is deadlock a concern?  Can you use OBL(OE) one big
> > lock over everything, or do you need individual locks on elements of
> > the data structure?
>
> > Can you use fire-and-forget access, or do you need return values from
> > your calls?  Do you need to wait for completion of anything?
>
> > 'xmlrpc': remote procedure calls might pertain.
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> My intention is to have one object which is updated by two threads, and
> read by a third... one updating thread takes user input, and the other
> talks to a remote server.  Which are children of the others really
> doesn't matter to me; if there's a way to handle that to make this work
> more efficiently, excellent.
>
> Yes, I can use a single lock over the entire object; finer control isn't
> necessary.  I also don't need to avoid blocking on reads; reading during
> a write is something I also want to avoid.
>
> I was hoping to end up with something simple and readable (hence trying
> 'with' and then regular locks first), but if pipes are the best way to
> do this, I'll have to start figuring those out.  If I have to resort to
> XMLRPC I'll probably ditch the process idea and leave it at threads,
> though I'd rather avoid this.
>
> Is there, perhaps, a sensible way to apply queues and/or managers to
> this?  Namespaces also seemed promising, but having no experience with
> these things, the doc did not get me far.

I will hack at your requirements for a while.