Re: [BProc] clone support

[<er...@he...>]

On Fri, Aug 01, 2003 at 01:14:58AM +0200, J.A. Magallon wrote:
> 
> On 07.31, er...@he... wrote:
> > On Wed, Jul 30, 2003 at 10:55:12PM -0400, Nicholas Henke wrote:
> > > On Tue, 2003-07-01 at 11:05, er...@he... wrote:
> > > > 
> > > > I believe clone works.  Most of the interesting stuff with clone is
> > > > local to the node and BProc doesn't get involved at all.  So, in
> > > > theory, it should be possible to make Java work.
> > > 
> 
> Sorry for the late answer...
> 
> I am running pthread programs on nodes with bpsh. It works fine with
> standard kernels and bproc (no so fine with kernels that have O1 sched,
> but that's another story...)
> They are not very pthread intensive, just spawn at the beginning, do
> heay render work and a bit of syncronisation and per-thread variables.
> 
> If you point to problems in your kernel, you can try with this:
> 
> http://giga.cps.unizar.es/~magallon/linux/kernel/2.4.22-pre9-jam1m.tar.gz
> 
> (patches on top of 2.4.22-pre9)
> 
> Some ideas. AFAIK, java threads are built upon POSIX pthreads, not clone
> directly. PThreads themselves are built upon clone() syscall.
> And here comes the funny part. Attached is a simple example of spawning
> a program over the cluster nodes with bproc, and on each node spawn tasks
> with glibc clone() call. If you build and link with -lbproc, it works.
> If you link with -lbproc -lpthreads (even if you don't use any pthread
> call), it does not work. So the conclussion is that libpthread is
> overriding the clone() glibc syscal, and breaks it.

Yeah, pthreads gets its dirty little fingers in a lot of places.  I
believe it mostly just tries to clean up with its wrappers around
fork, clone, etc.

Another unfortunate side effect of the pthreads implementation is that
it does not recognize bproc_rfork, etc. as fork-like calls so the
child process is sometimes hosed if those are called from a
pthreadeded program.  The whole mess is severely flawed, IMO.

- Erik

P.S. I'm talking about Linuxthreads here, not NPTL.  I haven't looked
at NPTL yet but it should be much less screwy.