Ethereal-dev: Re: [ethereal-dev] Viewing packets while capturing...
> I was talking about what Sun calls "Solaris Threads and POSIX Threads"
"Solaris threads" are, as indicated, "UI threads".
> 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.
Yes - I said that in my message. The question is not what *those* OSes
do, the question is what *other* OSes do.
Some of them have threads packages implemented purely in userland, which
means that, unless they provide a "wrapper" library of the sort I was
talking about, a blocking system call executed by a thread in a process
will cause *the entire process* to block, not just the thread that makes
the system call.
Such a wrapper library would have to do something such as:
put file descriptors into "non-blocking" mode, whenever
possible;
have wrappers for "read()" and "write()" that catch the "this
call would block" error - and writes that don't write all the
data, which are writes that would block if they attempted to
write all the data - and mark the thread making the call as
blocked, remembering the file descriptor on which the call was
made;
have similar wrappers for other potentially-blocking system
calls, such as "select()" or "poll()" (which would have to do
a non-blocking "select()" or "poll()", and, if no descriptors
are ready for I/O, remember all the descriptors and mark the
thread making the call as blocked);
have the main loop of the thread dispatcher do, if all threads
are blocked, do something such as a blocking "select()" or
"poll()" on all the remembered descriptors and, when that call
returns, mark as runnable the threads blocked on those
descriptors and run one of the runnable threads;
handle timeouts in selects, "alarm()"/"setitimer()" alarms, etc.
As Ethereal is an X application, it will probably do "select()"s or
"poll()"s, because the X library waits for events with a "select()".
Thus, a wrapper for "select()" or "poll()" would be necessary. Wrappers
for calls it doesn't make - or for ones where it doesn't matter if all
threads are stuck if the call blocks - wouldn't be required.
In addition, the OS's raw packet capture mechanism would have to allow
non-blocking I/O and "select()"s or "poll()"s on any file descriptors it
uses, so you can wait for a packet to arrive without, say, blocking the
X user interface code.
> 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.
You may not care, but there are very likely to be other people who *do*
care. People may want to run Ethereal on SunOS 4.x, or Digital UNIX, or
BSD/OS, or {Free,Net,Open}BSD, or HP-UX, or AIX, or SINIX, or SCO UNIX,
or UnixWare, or.... (Many of those are supported by "libpcap"; others
aren't, but the "INSTALL" file discusses how it might be possible to
make them do so.)
Digital UNIX, and recent versions of UnixWare, have, as far as I know,
threads that the kernel knows about, so that if a thread in a process
executes a blocking system call, only the thread stops running, not the
entire process. I think the latest versions of HP-UX and maybe AIX may
have that as well, but I have the impression that there may be older
versions that either don't have threading support or that have userland
threading support, the latter probably requiring the sort of wrapper
library described above.
I can't speak for BSD/OS. I have the impression that the POSIX threads
libraries for {Free,Net,Open}BSD are userland-only; I don't know if they
also have a wrapper library.
I also don't know whether all of the OSes in question have thread-safe
libraries, including, if necessary, thread-safe X libraries (I have the
impression that GTK+ may expect all UI code to run in one thread, which
might obviate the need for a thread-safe "-lX11", say).
It may be that some of the platforms listed are ones of which few enough
users would want to use Ethereal that we don't have to worry about them
- but I wouldn't necessarily *assume* that of any platform. I
*definitely* wouldn't assume no {Free,Net,Open}BSD user would care about
Ethereal, and probably wouldn't assume that about BSD/OS, either.
