is it safe to stop a thread?

[Marcin 'Qrczak' Kowalczyk]

Wed, 23 May 2001 06:20:21 GMT, Eric Lee Green <eric at badtux.org> pisze:

> thread a grabs the semaphor protecting the global socket.
> thread b kills thread a.
> thread c tries to grab the semaphor protecting the global socket.
> 
> *DEADLOCK!*.

Concurrent Haskell allows throwing exceptions to other threads.
This includes the ability to kill threads and to defend from killing.

Catching such exceptions doesn't eliminate all races, so there is also
the possibility to block and unblock asynchronous exceptions around
really critical sections.

I believe that Python doesn't allow killing threads because it's
hard to provide in all threading environments. It is possible to
avoid deadlocks when threads are killed (but it's also possible to
not avoid them).

> Threads are evil.

Not at all (if done right).

> They are evil, wicked nasty things because there's no easy way to
> free the resources that a thread has allocated if the thread dies
> or is killed, unless you do some very tedious book-keeping.

Garbage collection with finalizers and modelling killing threads as
exceptions take care of this.

> Unfortunately, some beknighted notion of "efficiency" has made
> threading the de-facto "standard" on most platforms for programs that
> must do multiple tasks, even though, on Linux at least, a thread
> spawn and a process fork are the exact same freakin' kernel call
> (just a different parameter), and take virtually the same amount of
> time (both create a copy of the page tables, the only big difference
> is that the process fork sets the copy-on-write flags for the pages).

Concurrent Haskell implementation doesn't use OS threads. Its threads
are much faster than Linux threads.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK