[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
mika at async.caltech.edu
Thu Apr 21 17:07:48 CEST 2011
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.
More information about the M3devel