[M3devel] pthread_atfork

[Daniel Alejandro Benavides D.]

Hi all:
by the way you told, do user space interfaces need to be linked differently from user space threads library than the one in kernel threads, so the behaviour can be selected better at runtime if more than one available processor (i.e a virtualized one, perhaps two if there are virtualized GPU, GPGPU, etc) is available on demand (in example the collector has its own user space thread allocated control and one in kernel space that user can control from the Runtime), could it work in such a way to allow a Thread to live in spaces that are accesible through like an NetObj.T, thus allowing it to communciate them through such an abstraction?
Perhaps this could allow to run the kernel threads with Modula-3 governance and if so put them to work or switch to kernel them to accelerate its process according to its demands and such debug them in a special API like the one in the SPIN OS, fairly more comprenhensive thread implementation of Mach, Cthreads (aka C Pthreads calls) and own strends. Also scheduling could be handled to manage both user/kernel level synchronization, the threads and also allow to change from having a specialized hardware-assisted virtualized processor to a non hardware-assissted virtualized processor (like an NetObj.T again), which is like the same situation for Modula-3 with just one processor so in case it needs, it does so. In any case thread and object migration are safely defined over Obliq.
Granted, this is same situation like was before the enter of virtualization hardware but again the whole idea of hardware-assisted virtualization was not new, even there is an article in which a PDP-10 is claimed has requirements to make it virtual in hardware (and I believe in software too). So SPIN could be a platform, like for hardware assissted virtualization and/or operating-system level virtualization, if so, we would be able to trace system calls for a given OS client running on it, rather than barely, so it makes the implementation with hardware-assisted source-level debugger ready, which is related to where programs are segfaulting now (no system-level breakpoints, that is, no hardware assisted source-level debugger for virtualization user, different from Modula-3 situation in current user-level space threading or SPIN gdb DEC TTD Topaz Tele Debugger at source-level service and not to forget the ldb cross-platform source-level remote debugger)
 in pthread current implementations, likewise the whole idea of customizable scheduler and kernel allocator weren't and aren't new nor bad at all, neither for us nor were for SPINers; remember the CSA Occam2 TRAC sourced OS SuperSetPlus machine which had from 16 up to 256  individual processors independently executable as according to their product info add it could be connected over LAN up to 16 Mac, PC, and Sun workstations, pretty much like a compilation and execution engine in one, pretty and good mussle to have to see running. They offered besides Occam2, C, C++, Modula-2, Pascal and FORTRAN, prolog and Ada with source level debuggers and Operating Systems as their Software products too. I hope this would be an scenario in some years to come, at least for any of us, if solet's see where and what this takes to/from us.
The main question will be whether this guys will allow enogh detail to drive their GPGPU or CPU, I hope this history doesn't repeat like it is and wasn't in the past of machine OSes sources, i.e braking traditional development etc.
I'm sorry for the long of the message.
Thanks in advance

--- El sáb, 12/2/11, Olaf Wagner <wagner at elegosoft.com> escribió:

> De: Olaf Wagner <wagner at elegosoft.com>
> Asunto: Re: [M3devel] pthread_atfork
> Para: m3devel at elegosoft.com
> Fecha: sábado, 12 de febrero, 2011 07:02
> I think it would be acceptable to say
> that pthread threading is
> broken on FreeBSD6 (as it is not officially supported any
> more).
> All the stuff below should be documented in the 'known
> problems'
> section. Especially the different behaviours of fork for
> user and pthreads. This should also be mentioned in the M3
> interfaces (source code)!
> 
> Also that to use use threads with FreeBSD requires to
> remove the
> -pthread flag, as Mika noted.
> 
> BTW, do we have a chapter explaining what to do to use user
> threads
> instead of the default pthreads?
> 
> Olaf
> 
> PS: Hint: this would be a great task for anybody lurking on
> the lists
> and trying to get involved :-)
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> >
> > I wrote that.
> >
> > As I recall, FreeBSD < 6 doesn't have
> pthread_atfork.
> >
> > I think that was based on reading the man pages.
> >
> > So, yes. What would you suggest?
> >
> >
> >
> >
> >
> > All this atfork stuff came about as part of getting
> cvsupd to work.
> >
> >   With pthreads/kernel threads. It
> historically worked, with   
> > Modula-3 user threads.
> >
> >   Modula-3 user threads have this funny
> property that all threads   
> > survive work.
> >
> >   With pthreads/kernel threads, fork
> gives you a new process with   
> > just one thread.
> >
> >    (Solaris has fork1 and forkall, and fork
> maybe used to be   
> > forkall, but now it is fork1).
> >
> >
> >
> >
> >
> > cvsupd is one of those slightly unusual programs that
> does "fork and  
> >  then do more work"
> >
> > as supposed to the more typical "fork and exec".
> >
> >
> >
> > Which is to say..I don't know. Maybe, don't expect
> pthreads to work   
> > on FreeBSD < 6?
> >
> > At least not in a process that ever calls fork? Or
> does "fork and   
> > then more work"?
> >
> >
> >
> >
> >
> > In reality, i think a lot of libraries have trouble
> with "fork and   
> > then do more work", but
> >
> > I don't know. I recall vague notices in the
> Apple/Darwin manpages   
> > not to assume
> >
> > this works -- the obvious implication that there is
> plenty of use of  
> >  pthreads e.g. mutexes,
> >
> > but relatively little use of pthread_atfork.
> >
> >
> >
> >
> >
> > You could perhaps replace all uses of fork with a
> function that   
> > called the fork handlers,
> >
> > then fork, then the other handlers. That is probably
> what I meant in  
> >  the comment
> >
> > about this being easy to fix.
> >
> > You might though then run into the problem that
> callers of fork can't do much
> >
> > before exec...oh, that's vfork I bet actually.
> >
> >
> >
> >
> >
> >  - Jay
> >
> >
> >
> >
> >
> >
> >> To: hosking at cs.purdue.edu
> >> Date: Fri, 11 Feb 2011 19:05:25 -0800
> >> From: mika at async.caltech.edu
> >> CC: m3devel at elegosoft.com;
> jay.krell at cornell.edu
> >> Subject: [M3devel] pthread_atfork
> >>
> >> Tony,
> >>
> >> What's RTProcessC.c doing?
> >>
> >> I note the following cryptic comment:
> >>
> >> /* NOTE: Even userthreads now depends
> >>  * on availability of pthreads.
> >>  * This can be fixed if need be.
> >>  */
> >>
> >> now further down we can read:
> >>
> >> #if defined(_WIN32) \
> >>         ||
> defined(__vms) \
> >>         ||
> (defined(__FreeBSD__) && (__FreeBSD__ < 6))
> >>     return 0;
> >> #else
> >>     while (1)
> >>     {
> >>       int i =
> pthread_atfork(prepare, parent, child);
> >>       if (i != EAGAIN)
> >>         return i;
> >>       sleep(0);
> >>     }
> >> #endif
> >>
> >> so on FreeBSD 5 (what I'm running on my "FreeBSD4"
> system),
> >> RTProcess.RegisterForkHandlers does nothing?
> >>
> >> Hmmm.....
> >>
> >>     Mika
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345
> 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com |
> Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 |
> USt-IdNr: DE163214194
> 
>