On Nov 6, 9:02 pm, sturlamolden <[EMAIL PROTECTED]> wrote: > On Nov 7, 12:22 am, Walter Overby <[EMAIL PROTECTED]> 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! :^) Andy -- http://mail.python.org/mailman/listinfo/python-list