Skip site navigation (1)Skip section navigation (2)
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>