[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

[Jay K]

> Unfortunately, no.  CVSup's ab/use of fork() only affects some
> software-engineering issues at the margin of the threading problem.
> It does do bad things to portability to have to support it.
> 
> The Modula-3 way of doing what CVSup does is to use Process.Create to
> create a new process.  If there is state in the current process that
> needs to be transmitted to the new process, Pickle the state and send
> it over a Pipe into the new process.  Using fork() to do a kind of 
> pseudo-shared-memory should not be necessary.  I think.


What cvsup does is more efficient. But I'm not sure if by much.
You get a bunch of read-only shared state, including sharing physical memory.
Most other forms of inter-process-communication will duplicate the data.


What cvsup does is not portable to Windows.
And is not efficient on Cygwin.
Though it is portable to Interix and efficient there.
The NT kernel supports fork() in the manner everyone is familiar with, but Win32 doesn't expose it.


Anyway, we still don't know what are the problems currently, and they might exist on Win32 also.
  Or at least there are problems on Win64. The test program needs to be tried on 32bit Windows.
  And we need to consider removing use of GetThreadContext, and probably SuspendThread/ResumeThread as well.


I understand the -pthread dependency might be undesirable in user threads and it should be
easy to remove it, with the tradeoff that direct fork() won't do the right thing (though it will be racy
and therefore often appear to work).



 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110421/6ddf997b/attachment-0002.html>