Date: Mon, 14 Feb 2000 19:12:51 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: freebsd-hackers@FreeBSD.ORG, robert+freebsd@cyrus.watson.org Subject: Re: uthread: setsockopt while other threads blocked? Message-ID: <200002150012.TAA05646@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> I'm using a threaded program to manage ipfw rules, and today discovered > the hardware that you cannot simultaneously have a thread blocking on a > recvfrom() on the raw socket to read icmp packets, and have another thread > perform a setsockopt() to manipulate the ipfw rules. Yea, it's because our threads library locks fds, so the set/getsockopt can't access the fd until the recvfrom() is processed. I kinda think the application should be responsible for protecting access to files, and that the threads library shouldn't have to do this behind the scenes. I'm not exactly sure what the POSIX spec has to say, or implies, in this regard. I'll have to have a look. > While it's easy to work around, opening a second raw socket, it seems like > a bit of a wate, and results in more packet delivery to userland than > necessary. Does the pthread spec address this? Would it be possible to > set/getsockopt on a socket while it's in use? For example, retrieve peer > information from a socket while a thread is blocked on reading the socket, > or set buffering parameters? I don't know if the POSIX spec addresses this. I'll see if I can find something in the spec about this. It doesn't seem like it would hurt anything to be able to set buffering parameters or retrieve peer info from the socket. As long as your not corrupting the data stream that would go to another thread that had previously issued a read request. I'd be very hesitent to change our current method of locking fd's though, without knowing how it would affect other applications. Do you have a sample application that you can try on other systems, like Solaris or True64? I'd be interested to see how Solaris handles this. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002150012.TAA05646>