From: Wim T. <wim...@ch...> - 2003-04-19 00:27:11
|
On Sat, 2003-04-19 at 02:07, Wim Taymans wrote: > On Sat, 2003-04-19 at 01:35, Benjamin Otte wrote: > > CVS Root: /cvsroot/gstreamer > > Module: gstreamer > > Changes by: company > > Date: Fri Apr 18 2003 16:35:47 PDT > > > > Log message: > > rewrite GstThread - should be quite a bit cleaner and does change state correctly now > > But not for any cothreaded scheduler implementation as you really need > to create the cothreads of the elements inside the thread's context... Thinking about this some more: We could solve this by delaying the cothread allocation to: - right before we try to schedule the group/element without a cothread - or when we enter the iterate function of the scheduler. The advantage would be that we can keep this gstthread implementation (which is indeed cleaner). The disadvantage would be that there would be more overhead when we schedule the group/element for the first time (cothread allocation). I think adding this delayed allocation to the cothread implementation makes most sense, it just has to check if the cothread is allocated in the same thread as the context before mmapping the stack, else it delays the mmap to when it enters the cothread loop. I think we should not ditch cothread all together or make it impossible in the future as they have much better properties latency-wise. Wim -- Wim Taymans <wim...@ch...> |