[M3devel] pthread_atfork

[Jay K]

I propose that RTProcess__RegisterForkHandlers be implemented at least 3 times:


no-op for Win32:
  just return 0
  It is tempting to have this assert(0) but that is wrong.
  The function will be called and should just do nothing.

  
as-is for pthread:
  call pthread_atfork
  
manually for userthreads:

FreeBSD < 6: does it have pthreads?
Can we declare such systems use user threads?


take a lock, maintain the three lists/growable arrays, whatever
probably implement it in Modula-3


VMS: Punt for now.
Maybe newer versions than I was using have it.


And then, introduce RTProcess__Fork.
Replace all calls to Unix.fork with it.
Also implemented around 3 times.


RTProcessWin32__Fork: assert(false)
 fork+exec must be implemented through higher level operations
 fork+do more work isn't possible


RTProcessPthread__Fork: return fork();

RTProcessUserThreads__Fork: wrapper around fork()
that handles the callbacks from RTProcess__RegisterForkHandlers.

RTProcessVms__Fork: assert(false) I think, unless newer VMS has fork().


One thing not stated here, is that I believe something "like"
pthread_atfork is somewhere between reasonable and actually needed,
on all Posix/Unix systems.

Because, what isn't well known here, but I think is true, is that
we depend on pthread_atfork (or a reimplementation thereof)
as described here, so that fork + do more work with user threads
behaves like pthreads, and doesn't have all the threads survive.

Or..and I assume the answer is no: Do we want fork + do more work
to keep all threads for user threads and keep only one thread for pthreads?
How it was for a long time, but we didn't discover until fairly
recently.

I'm 99% sure this is all exactly correct.
Possibly this is enough explanation for others to do it.
Otherwise, maybe I'll get to it "soon". Maybe.


This doesn't help us figure out what is wrong with our pthreads implementation.
It just makes user threads not require -pthread.


 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110419/97c19ed9/attachment-0001.html>