Threading woes

[Cameron Laird]

In article <v%nc6.3118$xn.831173 at typhoon2.ba-dsg.net>,
David Allen <s2mdalle at titan.vcu.edu> wrote:
			.
			.
			.
>Now my question.  I'm trying to implement a STOP button.
>When the user clicks it, the program should stop what
>it's doing *IMMEDIATELY* and go idle.  Currently
			.
			.
			.
>threads or signal yourself, so I'm pretty much at
>a dead end with the threading solution with regard
>to the STOP functionality.
>
>So why not fork() processes, and then have them 
>communicate via sockets or something?  For interruption,
>I can just signal the download thread with SIGINT!
>This would work, but fork is UNIX only, and I need portability
>to at least windows.  Macs aren't that important
>right now.  I'm developing on linux by default.
			.
			.
			.
>- It is interruptable at any moment.  (i.e. if 
>networking is down, and I call gethostbyname or recv, the
>user doesn't have to wait for gethostbyname to fail
>miserably before actually stopping)
			.
			.
			.
You're stuck.  We're all stuck.  There is no
currently satisfying solution for this.

MacOS supports co-operative concurrency.  There
are a lot of situations where you canNOT retrieve
control from the OS, no matter what you do.

Win* is feasible, barely.  There's at least one
extension, I believe, that uses native threads to
give you what you're after.  It's not part of the
Python "core"; one of us needs to confirm that it
works reliably.
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html