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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
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
> [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
