Fwd: Re[3]: [Gc] FW: GC: Time for GC final release? (draft patch for cancellation)

Ivan Maidanski ivmai at mail.ru
Thu Jul 29 13:29:36 PDT 2010

Hello, Hans!

Could you try to answer the questions bellow? I'm still puzzled with.

Tue, 13 Jul 2010 15:27:43 +0400 Ivan Maidanski <ivmai at mail.ru>:

> Hello!
> This is a draft/incomplete (and NOT working) patch for case 1.
> It is not working because: I don't know how to do GC_enable for pthread_exit (since it is a no-return function). In GC_thread_exit_proc? Any ideas?
> Q: Will pthread_cancel() interception really help us, since it it just a send-signal routine (I mean it does not wait for the thread exiting, AFAIK)?
> Another question: is it enough for pthread_cancel/exit (and also GC_start_routine) to use GC_disable, or we need something close to disable_gc_for_dlopen?
> Fri, 9 Jul 2010 01:19:06 +0000 "Boehm, Hans" <hans.boehm at hp.com>:
> > It seems to me that we really want two patches related to cancellation that aren't yet in the tree:
> > 
> > 1) We should deal with the fact that apparently on Solaris and probably on Linux we can't collect while a thread is exiting, since signals aren't handled properly.  This gives currently gives rise to deadlocks.  I think the only workaround is to also intercept pthread_cancel and pthread_exit and disable GC until the thread exit handler is called.  That's ugly, because we risk growing the heap unnecessarily, and possibly repeatedly.  But it seems that we don't really have an option in that the process is not in a fully functional state while a thread is exiting.
> > 
> > 2) ...
> > 
> > I was hoping to find some time to work on this this week. But so far, it looks like I failed.
> > 
> > These are both a bit frustrating, because I think they're really problems in the underlying Posix layers that are likely to also affect other things.  And they don't seem to admit good solutions
> > 
> > Hans
> > 
> > > -----Original Message-----
> > > From: Ivan Maidanski [mailto:ivmai at mail.ru]
> > > ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 7212 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20100730/7eb7a462/attachment.obj

More information about the Gc mailing list