From owner-freebsd-hackers Mon Feb 14 16:49:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by builder.freebsd.org (Postfix) with ESMTP id BCF2E4C00 for ; Mon, 14 Feb 2000 16:48:08 -0800 (PST) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 401; Mon, 14 Feb 2000 16:44:15 -0800 Message-ID: <19c101bf774e$2eead6c0$1e80000a@avantgo.com> From: "Scott Hess" To: "Daniel Eischen" , , References: <200002150012.TAA05646@pcnet1.pcnet.com> Subject: Re: uthread: setsockopt while other threads blocked? Date: Mon, 14 Feb 2000 16:47:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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" To: ; 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