> >> It's in src/lib/libpthread
> >
> > Cool! Thanks everyone - all is fine now :-)
>
> Please torture it a bit, threaded programs used to be a little tricky.

ok, shall do :-)

> I'll list a few observations and I'd like to know if it's just me or if
> others can confirm them.
> For instance firefox didn't really work prior to newlock2 - it would
> either crash on startup or show a messed up user interface ( as in text
> misplaced and with wrong attributes ). Now it's rock stable ( by
> firefox standards at least ). I'm using pkgsrc/www/firefox.

when was newlock2 introduced?
Judging from http://mail-index.netbsd.org/current-users/2007/02/08/0001.html
it was around 2007...

I think my NetBSD v3 (albeit on AMD Athlon, i386port) is quite before
that time and I found it was/is always quite stable with firefox
(running w/o swap partition, but rather with swapctl on file which is
encrypted via cgd).

The only thing I was able to experience (problem-wise) was running Ion
(http://modeemi.cs.tut.fi/~tuomov/ion/) window manager with my video
app (http://www.vislab.uq.edu.au/research/accessgrid/software/advideo/status.html)
which is, potentially, pthreads-hungry AND it uses X(Un)LockDisplay
quite a bit... when switching the display between various windows I,
occasionally, was able to lock the program... but then again (even
though I could not reproduce the problem on linux) it could just be my
code that is the source of a problem :-)

So in short, I didn't have any real pthread-related problems on NetBSD
3 (in fact, recalling it now, it was also running fine with audio i/o
app on Celeron box which used 2 or 3 pthreads and DMA access on
soundcard)... just my 2 cents...

In comparison to Linux, I have recently noticed (man pthread page)
that there are a few env. variables to control pthreads
scheduling/behaviour - may be they have some effect on stability
issues? What are your settings wrt aforementione envs?