Mon May 22 13:11:52 PDT 2000

So , after a long fight I have Japhar compiled and running "Hello, world!" program with the following result:

[zaitcev@js006 java]$ /usr/local/japhar/bin/japhar --classpath=.:/usr/local/lib/classes.zip Hello
Hello, world!
Assertion failure: mon != NULL, at ../../../../nsprpub/pr/src/pthreads/ptsynch.c:470
fatal signal handler called, signal = 10
Bus error (core dumped)

Now I am faced with a task of debugging a huge blob of code, roughly divided between NSPR and pthreads. I reckon that I could cut my task in half if I dispose of pthreads. I tried to discuss that with helpful hacker comrades (yeah, right):

On #mozilla:

<zaitcev> What sort of threading does Mozilla use on Linux/i386?
<zaitcev> I am asking in the following context:
<zaitcev> If it uses pthreads, then we have a stack Mozilla->NSPR->pthreads->kernel <zaitcev> (if pthreads are considered a part of libc, heh)
<shaver> zaitcev: yes, that's true
<zaitcev> But I wonder if it is feasible to put NSPR on top of kernel, without pthreads.
<shaver> yes
<zaitcev> This is a quote from NSPR overview
<shaver> user-space threads via setjmp are in NSPR
<zaitcev> The
<zaitcev> operating systems provide everything from no concept of threading at all up to and including sophisticated,
<zaitcev> scalable and efficient implementations. NSPR makes as much use of what the systems offer as it can.
<zaitcev> Yes, but look at it this way: NSPR has a pile of code that can work off some simple abstractions
<zaitcev> Such as setjmp
<zaitcev> So, why don't we make a same or smaller pile of code to work off Linux kernel
<shaver> you could
<shaver> is there a lot of gain there?
<zaitcev> shaver: Suppose I do something like that, would it be useful for Mozilla?
<zaitcev> Yeah, do we get any speed?
<zaitcev> My problem at the moment is that I am stuck with a system with buggy pthreads, they fault assertions. I can fix and replace kernel easily, but I am afraid of touching libc and other libraries
<zaitcev> So I thought why don't I sidestep that
<shaver> knock yourself out
<shaver> or ask on the NSPR list (mozilla-nspr@mozilla.org)
<zaitcev> ok

On #linux

<zaitcev> Was Brother Yosh or Don Miguel around?
<zaitcev> I need a hint about threading from a userland expert, e.g. what threading packages are available, what does kernel provide, and what code can I read (besides sys_clone() :)
<_Anarchy_> zaitcev: glibc provides most of posix pthreads
<_Anarchy_> Apache has a threading library
<_Anarchy_> Netscape has a nice MPL threading library
*>* prumpf (prumpf@p3E9C29B3.dip.t-dialin.net) has joined channel #linux
<_Anarchy_> and there is clone() which is what real men use
<_Anarchy_> pthreads is painful, badly designed and a crock to make it work user and kernel space
<_Anarchy_> clone is a bit too raw
<_Anarchy_> NSPR looks a nice balance
<phil> _A_: NSPR will be dual licensed if it's not already, unless I'm mistaken
<shaver> phil: still collecting permission from the many contributors
<phil> ah, ok.
<zaitcev> _anarchy_: NSPR has several variants inside, depending on the underlying implementation. e.g. ./configure time options. So NSPR either runs on top of pthreads or on top of setjmp and signal.
<prumpf> NSPR is what netscape uses ?
<wiggy> setjmp and signal? that sounds evil
<phil> prumpf: NSPR == NetScape Portable Runtime
<prumpf> (or mozilla)
<zaitcev> My problem is that my pthreads are buggy and NSPR breaks
<prumpf> thanks
<Micksa> _A_: do glibc peethreads use clone(2)?
<shaver> 4.x used NSPR 1.0
<_Anarchy_> micksa; yes
<zaitcev> So I thought why not to write NSPR code that works over clone().
<shaver> Netscape servers use NSPR 2.0 and 3.0 now
<zaitcev> Shaver sais it's dumb
<_Anarchy_> zait: so fix your peethreads
<_Anarchy_> Apache has a similar lib too
<Micksa> woo, I've coined a term :)
* _Anarchy_ sprays air freshener
<zaitcev> "<_Anarchy_> pthreads is painful, badly designed and a crock to make it work user and kernel space"
<Micksa> _A_: is clone(2) optimal? or has it been kludged up to work with peethreads?
<shaver> Apache should have just used NSPR, but they were silly
<zaitcev> Why bother to fix them if we better use NSPR as the interface
<shaver> oh well, their loss
<_Anarchy_> Micksa: clone() is basically optimal
<arjan> _A_: Unless you must have portability
<_Anarchy_> arjan: to what ? NT doesnt use pthreads, macos doesnt use pthreads
<_Anarchy_> *BSD emulates clone() nowdays
<arjan> _A_: I thought there was pthreads for NT
<_Anarchy_> arjan: not seen it
<shaver> Micksa: widely implemented?
<shaver> Micksa: "usable on greatest number of platforms" is probably NSPR
* arjan will convert his code to clone() tomorrow
<zaitcev> So in the end I do not follow what _A_ suggests. Either "<_Anarchy_> zait: so fix your peethreads" or "<_Anarchy_> pthreads is painful, badly designed"
<_Anarchy_> you said yours were broken
<zaitcev> If they are bad, I do not need to fix them, as I need to use NSPR anyways
<_Anarchy_> zait:glibc has support binaries depending on pthreads btw
<Micksa> shaver: yeah well you would say that :)
<Micksa> shaver: I was hoping for one that I could count on to be already installed on any machine.
<zaitcev> _A_: "support binaries for libc", this is a novel concept... are you talking about PAMs?
<_Anarchy_> zaitcev: nscd
<zaitcev> Ah
<zaitcev> I don't think I have it running
<_Anarchy_> zait: the pty get stuff is a support binary too for example - so it has some
<_Anarchy_> but nscd is the pthread usr
<_Anarchy_> and stuff like current gimp 8)
<shaver> Micksa: NSPR is pretty widely installed, but it would be a pain to link against in some forms
<Micksa> shaver: is it its own .so? :)
<shaver> Micksa: with Mozilla yes, with Communicator no, with Netscape servers usually
<Micksa> hmm, with a bit of fooling around I guess I could set up some auto* stuff that checked for an already installed .so, and just compiled and installed it if it wasn
<Micksa> wasn't there.
<shaver> Micksa: we have such autoconf stuff in Mozilla already, if you'd like to crib

It does not pay to be an IRC junkie.