python's threading has no "interrupt"?

Dave Brueck dave at
Tue Dec 2 17:42:16 CET 2003

Jay wrote:
> >You've noticed that there isn't an identical construct for what you were
> >in Java, so it may be that the Python way will be a completely different
> >approach to the problem rather than just a direct conversion from Java to
> >Python syntax.
> Well, I'll give an example from something I tried to do a few years ago
> which I couldn't translate to Python, though I took a stab at it.
> The language in question was a VM language with it's own internal
> process model.  The process model was all inteneral to on eOS process to
> it was a cooperative model of multi-threading
> The application I wrote was a web server on the front of an application
> so that web requests were all handled in the application.  IOW, the
> application had a web server interface)
> The language process model had both the ability to set process
> priorities, as well as allow processes to sleep and cede control to
> other processes.
> When a web request would come in, the handling of the request would be
> forked as a seperate process so that the server could accept the next
> request.  Both the server process and the handling process(es) were at
> the same priority level so in theory each process would run to
> completion before allowing another process to run.  For this reason,
> both the server process and the handling processes would issue a 'yield'
> at periodic strategic points, allowing themselves to temporarily halt
> and for the next process of equal priority that was waiting to run.

So, if I understand this correctly, this amounted to a manual task switcher,
right? (as no more than one job was allowed to run concurrently). Was this
really the desired behavior? If each process halts while the others run and
does so only to prevent starvation in the other processes, wouldn't you get
more or less the same results by just using normal forking/threading wherein
the OS ensures that each process/thread gets a slice of the CPU pie? (IOW,
unless there was some other reason, it seems that the explicit yielding was to
work around the constraints of the process model).

> Behind all of this was a higher priority process running, but it
> basically would sleep for several minutes (sleeping allowed lower
> priority process, like the server process to run).  When the background
> process would wake up, since it was a higher priority, it would
> immediately take control.  It's main job was to check the list of
> handling processes for any that had been running too long (long running
> processes in a web server meant that something had gone wrong) and
> terminate them (freeing up the process and socket resources, etc..).

If you're using forking to handle new processes, then you can simply kill them
from Python and you'll get the same behavior you specify above. Stopping a
thread isn't supported because there's no way to know the state of the
resources that were in use when the thread was killed (e.g. what if it was at
the time holding a mutex that other threads will want to use?) - this isn't
really a Python issue but an OS one. The fact that Java threads even _had_ a
stop() method seems dangerous, and it looks like Sun thinks so too: - "void stop()
Deprecated. This method is inherently unsafe. "
(I mention this since that's what the OP was using)

So... what was going wrong that warranted killing the process in the first
place? In practice the need for that is pretty rare, especially for a server,
the main case coming to mind being the execution of user-supplied code (which
is pretty scary in and of itself!).


More information about the Python-list mailing list