Re: Simple BSD Sockets question
Re: Simple BSD Sockets question
- Subject: Re: Simple BSD Sockets question
- From: Pelle Johansson <email@hidden>
- Date: Thu, 25 Nov 2004 11:30:56 +0100
2004-11-25 kl. 00.20 skrev Paul Forgey:
In my experience, it's a lot more reliable to close the socket unless
the signal handler exits the process. Taking a sideways exit out of
the process is fine for simple things, but gets ugly if you need to
cleanly shut things down (like database files), especially if you have
threads.
If you depend on accept failing with EINTR, the signal may not arrive
while blocking on the accept call. If you happen to get the signal
just before or after the accept call, you won't notice. Polling a
global shutdown flag set in the signal handler still doesn't help
because you may get the signal after checking the flag but before
blocking in the accept call.
In your case, you could just close the socket in the signal handler.
I might have misunderstood the OP, but how would you close a socket if
you are currently in a blocking accept call? And if done from another
thread, the problem is once you have closed an fd, it becomes available
for open again, and you have a potential race issue. I wouldn't
recommend closing a fd from another thread than which is using it, but
if you feel you have to, make sure you invalidate the variable the
other thread is using before the close.
I'm unsure if this was a multithreaded application though, and if not
I'd go with either closing the socket and invalidating the fd from the
signal handler. Even better would probably be to not even enter the
accept call the last time, but perhaps that's not possible. Perhaps the
OP can tell us how the process knows when it's supposed to quit?
Once you get past that first simple socket usage, you should probably
be using select(2) or kqueue(2) to wait for data. That way you will
only call the system calls when there's data available in them, and
they won't block. You probably shouldn't spawn one thread per
connection unless you have special needs.
--
Pelle Johansson
<email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden