Vsevolod <vselo...@gmail.com> writes: > "This should be used with caution: it is implementation-defined > whether the thread runs cleanup forms or releases its locks first." > This doesn't mean deprecated. It means: implementation-dependent. For > example in SBCL: "Terminate the thread identified by thread, by > causing it to run sb-ext:quit - the usual cleanup forms will be > evaluated". And it works fine.
I'm curious - do you know what happens if threading is implemented as a native OS thread and it's stuck in an I/O operation that is blocked? How does the Lisp interpreter/runtime gain control again in order to execute the specified function? I guess on many POSIX-ish environments, internally generating a SIGALRM to interrupt a system operation might work, but it would likely have portability problems. Or is that combination (native OS thread and/or externally blocking I/O) prevented by the runtime somehow (perhaps by internally polling what appears to code as blocking I/O)? But surely if there's an access to OS routines, the risk of blocking must be present? That scenario is really the only rationale use case I've run into for wanting to kill a thread, since in other cases the thread can be monitoring for an application defined way to shut down. -- David -- http://mail.python.org/mailman/listinfo/python-list
