Waking up a thread that's blocked on sock.recv()
Grant Edwards
writes stuff to a socket and a second that reads from the
socket.
Sometimes I want to kill the reading thread. Since there isn't
a way to kill a thread (right?), is there a way to wake up a
thread that's blocked so that it can figure out it should exit?
Right now the program works -- sort of. A series of sockets
are used and I end up accumulating blocked receive threads and
open TCP connections which don't get closed until the program
exits.
I expected a blocking recv() in one thread to return when
another thread closes the socket, but it doesn't seem to.
--
Grant Edwards grante Yow! I'm having fun
at HITCHHIKING to CINCINNATI
visi.com or FAR ROCKAWAY!!
Aahz Maruch
Grant Edwards <gra...@visi.com> wrote:
>
>Sometimes I want to kill the reading thread. Since there isn't
>a way to kill a thread (right?), is there a way to wake up a
>thread that's blocked so that it can figure out it should exit?
Use timeoutsocket.py, select(), or non-blocking sockets.
I'll not get into the argument about whether Python "should" support
killing threads -- I've insufficient expertise for that.
--
--- Aahz (Copyright 2000 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"Lying. Cheating. Stealing. Hurting people. These things are bad.
Eating pastry is not bad. Get a grip!" --jwermont
Grant Edwards
>In article <NmTV5.389$%Q3.4...@ptah.visi.com>,
>Grant Edwards <gra...@visi.com> wrote:
>>
>>Sometimes I want to kill the reading thread. Since there isn't
>>a way to kill a thread (right?), is there a way to wake up a
>>thread that's blocked so that it can figure out it should exit?
>
>Use timeoutsocket.py, select(), or non-blocking sockets.
>
>I'll not get into the argument about whether Python "should" support
>killing threads -- I've insufficient expertise for that.
I'd thought of using select to allow the reader to wake up
periodically to see if it should exit, but I thought maybe
there was a more direct way to interrupt the recv() call.
--
Grant Edwards grante Yow! HELLO KITTY gang
at terrorizes town, family
visi.com STICKERED to death!
Joshua Muskovitz
(set by the other thread) to see if you should die. This is the exact
solution I use for the same problem. (I send info via one thread, and recv
via another thread.) The only thing is that there is an undefined (but
limited) amount of time between setting the "kill yourself" variable and the
thread dying, since you have to wait for the next timeout to expire.
Using non-blocking sockets is a bad idea, since a thread doing lots of
recv() calls sucks up CPU like mad. I've not looked into timeoutsocket.py
myself.
-- j
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Donn Cave
| In article <908vvf$4vt$1...@panix2.panix.com>, Aahz Maruch wrote:
|>In article <NmTV5.389$%Q3.4...@ptah.visi.com>,
|> Grant Edwards <gra...@visi.com> wrote:
|>>
|>> Sometimes I want to kill the reading thread. Since there isn't
|>> a way to kill a thread (right?), is there a way to wake up a
|>> thread that's blocked so that it can figure out it should exit?
|>
|> Use timeoutsocket.py, select(), or non-blocking sockets.
|>
|> I'll not get into the argument about whether Python "should" support
|> killing threads -- I've insufficient expertise for that.
|
| I'd thought of using select to allow the reader to wake up
| periodically to see if it should exit, but I thought maybe
| there was a more direct way to interrupt the recv() call.
If I were using select that way, I think I might create a control
pipe to add to the select mask. Select blocks forever, then wakes
when close of the pipe's other end makes the select end readable.
Might make the write end "close on exec" (man fcntl), to keep child
processes from holding it open by accident. Or you could make more
of the pipe and pass various kinds of control messages.
But if someone has to wake up periodically and do this "should exit"
analysis anyway, it might as well be the blocking thread, so your
select timeout is a more direct solution. I propose the control
pipe in case there's an event basis for "should exit."
Donn Cave, do...@u.washington.edu
Grant Edwards
> Use select to force a timeout on the socket, and then use a
> magic variable (set by the other thread) to see if you should
> die. This is the exact solution I use for the same problem. (I
> send info via one thread, and recv via another thread.)
That's pretty much what I decided I'm going to do -- on Monday :)
> The only thing is that there is an undefined (but limited)
> amount of time between setting the "kill yourself" variable and
> the thread dying, since you have to wait for the next timeout
> to expire.
At least you can trade off response time against CPU wastage.
> Using non-blocking sockets is a bad idea, since a thread doing
> lots of recv() calls sucks up CPU like mad. I've not looked
> into timeoutsocket.py myself.
Me neither. I've used select in other programs, and will
probably use it here.
Perhaps I run into an odd bunch of applications, but this seems
to be a pretty common problem with no nice solution.
One real-time OS I'm using (eCos) has added a system call to
wake up everybody currently blocked on a select(). It's sort
of hackish, since you have to wake up everybody, but it's
better than nothing.
With full-blown Unix processes you can arrange for signals to
interrupt system calls, but I've not done much with threads in
non-real-time OSes, so I don't know how such things are handled
in pthreads et al.
--
Grant Edwards grante Yow! I feel real
at SOPHISTICATED being in
visi.com FRANCE!