Ethereal-dev: Re: [ethereal-dev] Viewing packets while capturing...
Guy Harris wrote:
> Is "libc_r" more than just thread safe in the sense *I* usually think of
> "thread safe", i.e. "you don't have to worry about thread B making a
> call that e.g. accesses some data structure if thread A is in the
> middle of updating that data structure"? I.e., is it *also* "thread
> safe" in the sense that it's safe for threads to make blocking system
> calls, *including, say, "select()"*, without fear that they'll block the
> entire process (which means that they're presumably not direct system
> calls, but wrappers around system calls, or are special "non-blocking"
> system calls, or something)?
>
> This includes "read()"s from - and, if we're going to support sending
> raw packets, possibly "write()"s to - "/dev/bpf", as well as socket
> reads and writes.
Won't mutexes/semaphores handle most of these issues? 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?
Wouldn't you say - read data into a buffer, check a lock, then move the
data to the protected structure, etc.??
I'm not sure that BSD's implementation of /dev/bpf is thread safe.
Maybe yes, maybe no. I've used /dev/bpf - but never in a threads
environment. Looking at the bpf code and then a bit of
experimentation/prototyping might answer these questions.
If I can help, let me know.
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 |
