[Gc] porting to Win32 fibers

Hans Boehm Hans.Boehm at hp.com
Wed Feb 8 19:47:40 PST 2006

Questions about different flavors of cooperative threads come up

I think the cleanest way is to really treat them as threads, and to
introduce a file analogous to either (pthread_support.c +
pthread_stop_world.c) or win32_threads.c.  It would have to implement the
functionality there, though the world stopping and starting functions
could be noops.

I think I did state in a previous reply that you could also just scan the
other stacks, and let the collector run in single-threaded mode.  But you
correctly point out a problem with that:  The single-threaded collector
does assume in a couple of places that it's running on the main stack.

Can a fiber cause a context switch by trying to perform output on a
blocking descriptor?  If so, there are some issues if you don't lock and
then have the collector generate a log, e.g. with GC_PRINT_STATS.


On Wed, 8 Feb 2006, Andrew McKinlay wrote:

> I'd like to port the collector to Win32 fibers, which are coroutines,
> more or less. Has anyone done this? I'm assuming they haven't, based
> on no mention of it.
> >From searching the archives, I think what I need to do is define
> GC_push_all_stacks. To do this it looks like I need to set
> GC_push_other_roots.
> However, the actual problem I'm seeing is a page fault in
> GC_clear_stack_inner, presumably because the stack limit is wrong for
> the additional stacks. It looks like the #ifdef THREADS version might
> work. Should I be defining THREADS ? What other impact would this
> have?
> Note: Fibers are "cooperative" so no locking is required.
> Is there anything else I should watch out for?
> Thanks in advance for any info, suggestions, advice.
> Andrew McKinlay
> https://suneido.com
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list