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

[Hendrik Boom]

On Thu, Apr 21, 2011 at 04:47:33PM +0200, Olaf Wagner wrote:
> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>
>> I'm not familiar with the architecture of CVSup.
>>
>> On Apr 21, 2011, at 10:28 AM, Hendrik Boom wrote:
>>
>>> On Thu, Apr 21, 2011 at 10:20:54AM -0400, Tony Hosking wrote:
>>>>
>>>> On Apr 21, 2011, at 9:19 AM, Hendrik Boom wrote:
>>>>
>>>>> On Wed, Apr 20, 2011 at 10:58:06AM -0400, Tony Hosking wrote:
>>>>>> Agreed.  But CVSup used it and we were trying to be supportive.
>>>>>
>>>>> So, at present, CVSup presumably works with user threads.
>>>>> Maybe the cure is to fix CVSup instead of fork().
>>>>>
>>>>> Why does CVSup needs a fork() that preserves all threads?  Is
>>>>> it essential to its design, or incidental?
>>>>
>>>> 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.

-- hendrik