Re: OS-implemented threads

[Matthew Flatt <mflatt@cs.utah.edu>]

[Collecting several replies into one message.]

Quoting "Will Fitzgerald":
> But I take it that only *OS* threads are going away?

That's my proposal. The thread system provided by default -- the one
that most everyone uses, and the one that works right on all platforms,
and the one that's at least "pre-emptive" from the perspective of
Scheme code --- will still be there.

Quoting Ilya Perminov:
> I would use it if it worked. Without native threads, I'm unable to use
> mzscheme threads, because I have some mzscheme extensions, witch use 
> blocking I/O. I think you have this problem too with both COM and ODBC
> extensions.

That's a good argument, and one that I hadn't thought of.

Fully OS-threading MzScheme doesn't necessary to solve the problem,
though. The extension that must call a blocking function can create
it's own OS-level thread, which is how various I/O primitives within
MzScheme are implemented for Windows and BeOS.

That solution is certainly less convenient, and it can be tricky to
implement, depending on the primitive. Nevertheless, I'm inclined at
the moment to push the complexity into a few extensions, instead of
spreading it throughout MzScheme.

Quoting Alexander Taranov:
> For the project we are working at OS-implemented threads
> would be of great value. If it would work i would use it.
> The project is live one and in case of using OS-threads
> you will not complain on the lack of bug reports :-)

As much as I appreciate bug reports, I'm even more eager to avoid the
bugs that make them necessary. :)

In your project, would OS-implemented threads be valuable due to
blocking function calls, as in Ilya's project, or would they be
valuable for making use of multiple processors? Or something else?

Quoting PJ Durai:
> But is it _impossible_ to make it so that multiple OS threads can call into
> (embedded) mzscheme? Right now it looks like only the os thread that
> initializes mzscheme can call into scheme again.

That sounds like a valuable direction to pursue. With the recent
changes to the way MzScheme interacts with the GC, I think I can
arrange the interface to allow different threads to call into MzScheme,
as long as they do so in a single-threaded manner (i.e., as long as the
host program puts a big mutex around the MzScheme interface).

Matthew