Ethereal-dev: Re: [ethereal-dev] Viewing packets while capturing...
Guy Harris wrote:
> (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
I was talking about what Sun calls "Solaris Threads and POSIX Threads"
which are compatible (can be used together, referencing the same
threads) and include sync. across process boundaries. Sun has
implemented threads as part of the OS and therefore almost all Sun
libraries are "thread safe", including I/O, unless specifically
documented as unsafe (see more below).
In a similar manner, SGI supports POSIX threads and IRIX threads
(essentially lightweight processes). SGI's STDIO (and other libs)
become thread safe when _POSIX90 and _NO_ANSIMODE are defined variables
are defined prior to compilation.
>
> 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.
The POSIX implementations by Sun and SGI are not just "wrappers", but
are part of a complete "package" including thread safe libraries -
including I/O.
I have no idea what old versions of SUNOS do - nor do I really care. My
UNIX clients almost universally use Solaris 2.5.1->2.7, IRIX 6.X or
Linux 2.X.
I have attached info from Sun which should help in this discussion - one
doc. discusses Solaris and POSIX thread compatibility, another doc.
defines Sun thread safety terminology and finally, a doc. of complete
Sun library thread safety info.
BTW, I have Solaris 7 and IRIX 6.2 and IRIX 6.5, Linux 2.0.36 and SMP
Linux 2.1.132 up in my lab, so I'll be glad to test code for whomever
(related to ethereal of course ;-)
Cheers,
Lyle
--
Lyle P. Bickley | Bickley Consulting West Inc.
lpb@xxxxxxxxxxx | 1697 Grant Road
V 650-428-0621 | Mountain View, CA 94040
F 650-428-0599 |
Attachment:
sundef.txt.gz
Description: GNU Zip compressed data
Attachment:
sunsafe.txt.gz
Description: GNU Zip compressed data
Attachment:
sunthr.txt.gz
Description: GNU Zip compressed data
