2.6, 3.0, and truly independent intepreters

[sturlamolden]

On Nov 7, 12:22 am, Walter Overby <walter.ove... at gmail.com> wrote:

> I read Andy to stipulate that the pipe needs to transmit "hundreds of
> megs of data and/or thousands of data structure instances."  I doubt
> he'd be happy with memcpy either.  My instinct is that contention for
> a lock could be the quicker option.

If he needs to communicate that amount of data very often, he has a
serious design problem.

A pipe can transmit hundreds of megs in a split second by the way.


> And don't forget, he says he's got an "opaque OS object."  He asked
> the group to explain how to send that via IPC to another process.  I
> surely don't know how.

This is a typical situation where one could use a proxy object. Let
one server process own the opaque OS object, and multiple client
processes access it via IPC calls to the server.


> I don't think he has Python objects to work with.  I'm persuaded when
> he says: "when you're talking about large, intricate data structures
> (which include opaque OS object refs that use process-associated
> allocators), even a shared memory region between the child process and
> the parent can't do the job."
>
> Why aren't you persuaded?

I am persuaded that shared memory may be difficult in that particular
case. I am not persuaded that multiple processes cannot be used,
because one can let one server process own the object.