Ethereal-dev: Re: [ethereal-dev] Viewing packets while capturing...
> I also checked out the thread libraries of SGI and Sun and found that
> both support OS threads (mutex/semiphores) and Posix threads in both UNI
> and SMP environments.
(I assume by "OS threads" you mean "UI threads", in the sense of the
threading API that UNIX International came up with, and which I think
AT&T's^H^H^H^H^HNovell's^H^H^H^H^H^H^H^HSCO's SVR4-based UNIXes also
support - sometimes called "Solaris threads", although, as indicated, I
think SVR4.2 ES/MP or whatever it got called, and the Unixwares derived
from it, also supported them; both the UI thread API *and* the POSIX
thread API support mutexes, although there's no pthread semaphore API -
I guess you use the POSIX semaphores.)
Yes, I knew that the Solaris 2.x package has threads the kernel (in a
sense) knows about (the model is what the "comp.programming.threads" FAQ
calls a "two-level" or "hybrid" model), and Irix probably does - the
point is that there are some OSes that, as far as I know, have threads
implemented purely in userland, which means that a "read()" system call,
say, will block not only the thread that makes the call, but the entire
process in which the thread runs, so that *all* threads block. This
means that either
1) a threaded program needs to be careful when making blocking
system calls, so that you don't end up with all your threads
stuck when you want one of them to be able to get work done
or to respond to external events
or
2) you need some wrapper library so that "read()" isn't a direct
system call that blocks the process.
There are, I think, userland pthreads packages that have such a wrapper
library (the SunOS 4.x userland threads package, with an API that was
neither UI threads nor pthreads, did - "-lnbio"); if there's such a
threads package for the platform in question, and the wrapper library
doesn't have limitations that get in the way of Ethereal using it,
great.
