Ethereal-dev: Re: [ethereal-dev] Viewing packets while capturing...
> Won't mutexes/semaphores handle most of these issues?
No. This particular issue has nothing to do with code in different
threads, for example, accessing the same data structures, and keeping
them from stepping on each other. It has to do with making sure that
thread A can go ahead and do a "select()", or a "read()" from (or
"write()" to) "/dev/bpf", without blocking *the entire process* (i.e.,
keeping *any* threads from making progress or responding to input) if
none of the descriptors being "select()"ed on are yet ready for I/O or
if "/dev/bpf" isn't yet ready for I/O.
> And as I
> understand it, thread safe libc's should prevent one from blocking
> system calls for a process. I think I understand your concerns - but I
> don't understand how/why one would want to block a system call?
In "blocking system calls", "blocking" is an adjective, not a verb -
"blocking system calls" means "system calls that block", not "causing a
system call to block".
If a "read()" call goes directly to the kernel read code, and threads
are purely userland threads, if there isn't yet any data to be read, the
"read()" call will block, if the file descriptor isn't in non-blocking
mode, which means that the process will not be allowed to execute - and
that means *no* code in the process will be executed, i.e. not only will
the thread that does the "read()" not be able to continue, no *other*
thread will be able to continue, either.
