Date: Mon, 14 Feb 2000 16:47:06 -0800 From: "Scott Hess" <scott@avantgo.com> To: "Daniel Eischen" <eischen@vigrid.com>, <freebsd-hackers@FreeBSD.ORG>, <robert+freebsd@cyrus.watson.org> Subject: Re: uthread: setsockopt while other threads blocked? Message-ID: <19c101bf774e$2eead6c0$1e80000a@avantgo.com> References: <200002150012.TAA05646@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
If you're really certain that you know what you're doing, you might consider using _thread_sys_setsockopt() to go behind the pthread library's back. Non-portable, and a really bad idea if you can get away without it (in this case, I'd probably go with the second socket unless I determined that it really was a drag on performance or something). Later, scott ----- Original Message ----- From: "Daniel Eischen" <eischen@vigrid.com> To: <freebsd-hackers@FreeBSD.ORG>; <robert+freebsd@cyrus.watson.org> Sent: Monday, February 14, 2000 4:12 PM Subject: Re: uthread: setsockopt while other threads blocked? > > 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 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?19c101bf774e$2eead6c0$1e80000a>