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

[Mika Nystrom]

Hendrik Boom writes:
...
>>>>>
>>>>> CVSup uses fork in an ill-defined way. fork is only well-defined   
>>>>> for use as fork+exec.  So, the fact that there are continuing   
>>>>> threads is immaterial.  CVSup wants to continue doing real work   
>>>>> (without exec) after fork.
>>>>
>>>> Does it need to use fork() at all?  Wuld it suffice to use Modula 3's
>>>> own thread system?
>>
>> Not for real word server applications, where one problem in a user
>> session would crash dozens of other sessions. At least this was what
>> John Polstra reported. The additional safety of separate address
>> spaces _has_ its advantages.
>>
>> I thought CVSup had been changed to work with pthreads though in CM3?
>> Or do I misremember?
>>
>> Anyway, this shouldn't be our most important problem, but rather make
>> System pthreads and also M3 user threads work in a reliable and
>> fault-free way again.
>
>Once our only problems are with CVSup's abuse of fork(), I'd 
>consider that done.

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.

     Mika