gamedevlists-linux

[GD-Linux] Cancelling blocking recv calls on Linux

[Hal A. <ha...@cl...>]

I wonder if anybody else has run into this and come up with a satisfactory
solution.

Part of my app uses TCP with blocking BSD sockets. Each "accept"ed
connection has its own thread which simply recv's data and pumps it into the
main thread.

This all works fine and dandy on Linux and Windows. The problem comes when
it comes to disconnecting the socket.

The worker thread will generally be blocked at the recv call and so the main
thread has to somehow overcome this - under WinSock1.1 a simple combination
of
	shutdown( fd_, RD_BOTH ); // fd_ is the file descriptor of the socket.
	WSACancelBlockingCall(); // (this is Winsock 1.1 so this call is fine).
Will cause the recv to immediately fail and the worker thread to terminate
and so the call to closesocket( fd_ ) doesn't lock and everything is great.

Under linux I use shutdown( fd_, SHUT_RDWR ) followed by close( fd_ ). This
close then locks - the recv call never returns.

I've tried:
Setting the socket to non-blocking just before the close (i.e. it will
already be involved in a recv call).

My current solution is to use pthread_cancel to cancel the recv thread. This
terminates the recv and the close then works fine.

Anybody got anything better or is this infact the correct way to use
blocking sockets with threads?

Re: [GD-Linux] Cancelling blocking recv calls on Linux

[Ryan C. G. <ic...@cl...>]

> Anybody got anything better or is this infact the correct way to use
> blocking sockets with threads?

Have you tried sending a signal to the blocked thread? When you do, recv()
should return -1 and set errno to EINTR. From there the thread can check a
global variable or something that symbolizes that the system is shutting
down, and exit cleanly if it's set.

--ryan.

RE: [GD-Linux] Cancelling blocking recv calls on Linux

[Hal A. <ha...@cl...>]

I saw EINTR in the man pages - I couldn't figure out which signal to the
thread though.

I would send the signal by doing something like this:
pthread_t threadId_;
pthread_kill( threadId_, SIGKILL );

(Kill actually kills my entire process not just the target thread).

Any ideas on the signal to use?

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Ryan
C. Gordon
Sent: 10 May 2002 14:49
To: gam...@li...
Subject: Re: [GD-Linux] Cancelling blocking recv calls on Linux



> Anybody got anything better or is this infact the correct way to use
> blocking sockets with threads?

Have you tried sending a signal to the blocked thread? When you do, recv()
should return -1 and set errno to EINTR. From there the thread can check a
global variable or something that symbolizes that the system is shutting
down, and exit cleanly if it's set.

--ryan.



_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: ban...@so...
_______________________________________________
Gamedevlists-linux mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-linux
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=554

RE: [GD-Linux] Cancelling blocking recv calls on Linux

[Ryan C. G. <ic...@cl...>]

> I would send the signal by doing something like this:
> pthread_t threadId_;
> pthread_kill( threadId_, SIGKILL );
>
> (Kill actually kills my entire process not just the target thread).
>
> Any ideas on the signal to use?

Hhmm...threads should be separate processes, so I didn't think it would
affect the signalling thread. Still, SIGKILL can't be
blocked/ignored/handled, so you shouldn't be using that anyhow.

You could try using signal() and setting up a do-nothing signal handler
for each thread when it first starts executing. After that, SIGALRM is
probably a good candidate. (Hypothetically, you could just have the thread
call alarm() before the blocking recv(), and if you get the signal, see if
it's time to shutdown, otherwise, reset the alarm() and go back to recv()
again...that may or may not be less ugly, depending on what your design
looks like.

If this is all too hackish for you, you could consider using select() with
the socket and polling for new data before calling recv(), which
will also avoid the blocking behaviour.

--ryan.