"Mark Haniford" <markhaniford@...> writes:
> In regards to win32 threading, am I correct to assume that there are
> ideas out there on how to implement them, but nobody knows if
> they'll actually work in practice? Or is it a matter of "we know the
> right thing to do, it's just a matter of doing the implementation
> and working out the kinks"?
I think that collectively we have a decent idea of a solution for most
problems, but it is going to take quite a bit of work yet.
Also, my personal belief is that in the long term it is better to work
out kinks in (1) unithreaded Windows port and (2) threads in general
before porting threads to Windows. I don't know how many people agree,
(1) Mysterious crashes depending on how you run SBCL. GC page-table
corruption (at last with 0.19.18 -- and even if this doesn't happen
anymore it needs to be investigated). Streams should use handles,
not fds. Serve-event issues. There are more, but these are the ones
I would fix before going on to threads.
(2) Foreground/background thread mediation without sessions (probably
delegate to streams). Optionally synchronized streams. Lingering
PCL thread safety problems.
That said, if a decent quality patch for threads on Windows were to
materialize, I would not mind merging it.
Quick notes on how to do it, maybe: Alastair had the idea of hiding
the thread-local storage in the SEH, which may seem slightly perverse
but is starting to grow on me. Windows threads are very
asynch-interrupt averse, but we will be able to build INTERRUPT-THREAD
from SuspendThread, GetThreadContext, SetThreadContext, and
ResumeThread. SuspendThread and ResumeThread will also work for GC. We
need to very be careful with race-conditions, though, as threads will
not be able to decline the suspension.
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."