[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OS-implemented threads



Quoting Alexey Mahotkin:
> Please try to compile it with --enable-osthreads.

This forces a question that's been on my mind, and I've been meaning to
take a survey.

With the recent changes to MzScheme, I inspected at a lot more code
than normal in a short time; and I saw lots and lots of bugs in the
support for OS-implemented threads, mainly in terms of unprotected
shared variables and structures.

Meanwhile, there's a tricky signal--select race in Unix, which can't be
solved in the same way as in single-threaded mode; I don't know how to
fix it. And we have little hope of properly supporting generic pthreads
(no way to pause threads for GC, I think) or LinuxThreads
(semaphore-wait is not breakable).

In short, MzScheme's support for OS-implemented threads has many
problems. Considering the significant maintenance overhead and clutter
required to support the mode, I wonder whether it's worthwhile.

In theory, OS-implemented threads provide the benefit of parallelism on
multiprocessor machines. In practice, that's where MzScheme would be
most likely to crash. Given the problems and the relative lack of bug
reports, I doubt that anyone uses it. Obviously I don't.

So, does anyone actually use MzScheme with OS-implemented threads?
Would anyone be seriously disappointed if we drop support for
OS-implemented threads in version 200?

(To be clear, we'll certainly make MzScheme work when embedded in a
multi-threaded application, as long as MzScheme itself is called from
only one OS-implemented thread.)

Thanks,
Matthew