[M3devel] pthread_atfork

Sat Feb 12 22:45:18 CET 2011

 > so the behaviour can be selected better at runtime if more than one available processor

I would like user vs. kernel threads to be selectable at link and/or run-time, but Tony has nixed the small changes required to make it so.
  It has also been suggested you could copy around different m3core.so files to switch, but that isn't the case either. Thread.T has a different typeid in the two systems.

Anyway, the better behavior is almost always kernel threads.
You should really just generally stick with them.

You do forever ongoing debate on these matters, and the "pendulum" has seemingly swung many times, so I can't really say
everyone agrees in kernel threads always.

Windows 7 adds "user mode scheduling", which is still kernel threads -- there is still a one-to-one mapping between
some usermode state and kernelmode state, but the scheduling decisions are made in usermode.

I believe pthreads on OpenVMS use the "m:n" approach.

But Linux, Solaris by default, Darwin, I suspect but am not sure FreeBSD and NetBSD, Win32 all use the simple "1:1" model.
Where every thread is a kernel thread. All scheduling is done by the kernel.
Win32 also has "fibers" but these are fairly...surprisingly difficult to use, but in a way that Tony et. al. wouldn't be surprised by.
When you use fibers, you have to write your own scheduler, and your own locking primitives. Normal Win32 functions
like GetCurrentThreadId(), EnterCriticalSection() become sort of useless/broken in the face of fibers.
Basically the same as what it takes to implement Modula-3 user threads.
Though you can run on multiple processors I believe fairly easily.
Hm. The "m:n" model is actually not difficult to implement on Win32 and w/ pthreads. But still, probably not a good idea.

 - Jay

> Date: Sat, 12 Feb 2011 21:08:13 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; wagner at elegosoft.com
> Subject: Re: [M3devel] pthread_atfork
> 
> 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
> > 
> > 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110212/46eea8dd/attachment-0002.html>