Another option might be to create a daemon thread that just sleeps all the time and catches the INTR signal. There are some issues with this, starting with the fact that it's an exception to the "only the main thread receives signals" fiat. It's also probably already been thought of, but IMHO an approach like that would be better than adding timeouts everywhere. -Jerry -O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O- -O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O- Aahz <aahz@pythoncraft.com> wrote: > On Mon, Mar 18, 2002, Guido van Rossum wrote: > > > > Yeah, unfortunately the only implementation technique I have to offer > > right now is to turn all acquire calls internally into a loop around > > an acquire call with a timeout in the order of 1 second, and to check > > signals each time around the loop. :-( > > -1 > > The problem with this is that you really start tying yourself in knots. > If you do a time.sleep() for one second, that can't be interrupted for a > full second, either on keyboard interrupt or on releasing the lock. The > finer-grained you go on time.sleep(), the more overhead you consume, and > the coarser-grained you go, the more you limit throughput. > > I'm not aware of any good cross-platform technique for managing thread > timeouts that is also "live".
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4