2.6, 3.0, and truly independent intepreters
andy55 at gmail.com
Mon Nov 10 19:58:46 CET 2008
On Nov 6, 9:02 pm, sturlamolden <sturlamol... at yahoo.no> wrote:
> 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.
Hmmm... Your comment there seems to be an indicator that you don't
have a lot of experience with real-time, performance-centric apps.
Consider my previously listed examples of video rendering and
programatic effects in real-time. You need to have a lot of stuff in
threads being worked on, and as Walter described, using a signal
rather than serialization is the clear choice. Or, consider Patrick's
case where you have massive amounts of audio being run through a DSP--
it just doesn't make sense to serialize a intricate, high level object
when you could otherwise just hand it off via a single sync step.
Walter and Paul really get what's being said here, so that should be
an indicator to take a step back for a moment and ease up a bit...
C'mon, man--we're all on the same side here! :^)
More information about the Python-list