2.6, 3.0, and truly independent intepreters

Andy O'Meara andy55 at gmail.com
Mon Nov 10 13:47:36 EST 2008


On Nov 6, 8:25 am, sturlamolden <sturlamol... at yahoo.no> wrote:
> On Nov 5, 8:44 pm, "Andy O'Meara" <and... at gmail.com> wrote:
>
> > In a few earlier posts, I went into details what's meant there:
>
> >http://groups.google.com/group/comp.lang.python/browse_thread/thread/...
>
> All this says is:
>
> 1. The cost of serialization and deserialization is to large.
> 2. Complex data structures cannot be placed in shared memory.
>
> The first claim is unsubstantiated. It depends on how much and what
> you serialize.

Right, but I'm telling you that it *is* substantial...  Unfortunately,
you can't serialize thousands of opaque OS objects (which undoubtably
contain sub allocations and pointers) in a frame-based, performance
centric-app.  Please consider that others (such as myself) are not
trying to be difficult here--turns out that we're actually
professionals.  Again, I'm not the type to compare credentials, but it
would be nice if you considered that you aren't the final authority on
real-time professional software development.

>
> The second claim is plain wrong. You can put anything you want in
> shared memory. The mapping address of the shared memory segment may
> vary, but it can be dealt with (basically use integers instead of
> pointers, and use the base address as offset.)

I explained this in other posts: OS objects are opaque and their
serialization has to be done via their APIs, which is never marketed
as being fast *OR* cheap.  I've gone into this many times and in many
posts.

> Saying that "it can't be done" is silly before you have tried.

Your attitude and unwillingless to look at the use cases listed myself
and others in this thread shows that this discussion may not be a good
use of your time.  In any case, you haven't even acknowledged that a
package can't "wag the dog" when it comes to app development--and
that's the bottom line and root liability.


Andy







More information about the Python-list mailing list