Re: [gtk-vnc-devel] [RFC] GThread based coroutines
- From: "Daniel P. Berrange" <berrange redhat com>
- To: Anthony Liguori <anthony codemonkey ws>
- Cc: gtk-vnc-devel List <gtk-vnc-devel lists sourceforge net>
- Subject: Re: [gtk-vnc-devel] [RFC] GThread based coroutines
- Date: Thu, 20 Dec 2007 22:43:52 +0000
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 configure.ac
> >
>
> 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.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- 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]