[Gc] porting to Win32 fibers
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
> 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
> 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
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc