Re: [gtk-vnc-devel] [RFC] GThread based coroutines

On Thu, Dec 20, 2007 at 05:17:05PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Tue, Dec 18, 2007 at 10:51:05PM -0500, Anthony Liguori wrote:
> >  
> >>Hi,
> >>
> >>Attached a thread-based coroutine implementation.  This should make the 
> >>Windows port much easier.  I've tested it with gvncviewer and vinagre 
> >>(with multiple tabs) so I think it works pretty well.  The basic idea is 
> >>to use a GCond and GMutex to run all threads in lock-step.  It was 
> >>tricky getting the ucontext coroutines working properly so 
> >>testing/review is greatly appreciated!
> >>
> >>Also, I'm hoping someone who has a bit more autoconf foo can help me 
> >>with the proper autoconf/automake integration.  We need to detect 
> >>ucontext in configure and if it's available, compile in 
> >>ucontext_coroutine.[ch], continuation.[ch].  Otherwise, we need to add a 
> >>dependency to gthread-2.0 and compile in gthread_coroutine.[ch].
> >>    
> >
> >Here's an updated patch with autoconf magic. There wre a couple of things
> >I needed to deal with:
> >
> >When we do 'make install' we also install the coroutine headers. This
> >doesn't work so well because your patch has #ifdef in the coroutine.h
> >to then #include either the gthread or ucontext header, and this #ifdef
> >depends on a variable set from
> >  
> I think the solution to this is to remove the gvnc functions from the 
> export and not install the coroutine headers.

We'd need to make gvnc stuff into a GObject so you can use it frrom
the KVM test stuff though, right ?

> >I observed that the structs required for ucontext vs gthread were more or
> >less the same except for the GThread * vs  struct continuation. So I 
> >unified
> >them into a generic 'void *context'. In the implementation this context 
> >points to a GThread * or a 'struct continuation *' as needed. The latter
> >means the 'container_of' trick doesn't work, so I simply added 'void 
> >*owner'
> >to the 'struct continuation'.
> >  
> Yes, you're on the right track, but I wanted to push the logic into the 
> continuation layer.

Yeah, that might be even simpler, if we just had 2 internal impls of
the continuation module

I'll let you carry on working against my patch now that the autoconf stuff
is done.

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules:              -=|
|=-               Projects:               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]