sbcl-devel

Hello all,
At http://www.lisphacker.com/temp/wthread-combined-1a.diff is a patch
containing some initial Win32 thread hacking.
http://paste.lisp.org/display/38635 contains transcripts from shortly before
this diff was taken (fixing the RESET-SIGNAL-MASK thing).
The patch contains a forward-port of my older x86-ebx-threading patches to
use EBX as a dedicated TLS block pointer, and a pile of changes to the
runtime code to at least compile with :sb-thread on win32. It has not been
tested beyond the simple smoke test of "does it break the build on x86 linux
or win32?", GC over multiple windows threads will almost certainly lose, and
the synchronization (futex) stuff has been stubbed out.
For Win32, I use customize-target-features.lisp to add :sb-thread,
:x86-two-arg-passing-regs, :x86-reserve-ebx, and :x86-ebx-threads. None of
these features are win32-specific; I used a Linux build to test the compiler
changes. :x86-ebx-threads depends on :sb-thread and :x86-reserve-ebx.
:x86-reserve-ebx depends on :x86-two-arg-passing-regs.
Now if we could get INTERRUPT-THREAD, GC, and some sort of mutexes running,
we'd be good to go.
--Alastair Bridgewater

Alastair Bridgewater wrote:
> At http://www.lisphacker.com/temp/wthread-combined-1a.diff is a patch
> containing some initial Win32 thread hacking.
> http://paste.lisp.org/display/38635 contains transcripts from shortly before
> this diff was taken (fixing the RESET-SIGNAL-MASK thing).
>
> The patch contains a forward-port of my older x86-ebx-threading patches to
> use EBX as a dedicated TLS block pointer, and a pile of changes to the
> runtime code to at least compile with :sb-thread on win32. It has not been
> tested beyond the simple smoke test of "does it break the build on x86 linux
> or win32?", GC over multiple windows threads will almost certainly lose, and
> the synchronization (futex) stuff has been stubbed out.
Cool stuff! Looking at the patch very quickly, am I reading it correctly
when I think that EBX is reserved only for Win32+threads?
Also: at one point you pursued hanging TLS data onto the exception
handler chain. I take that this is no longer on the agenda?
Cheers,
-- Nikodemus

Nikodemus Siivola writes:
> Cool stuff! Looking at the patch very quickly, am I reading it correctly
> when I think that EBX is reserved only for Win32+threads?
Not quite. There's a combination of *features* which will use EBX for TLS
on Linux (or any other 32-bit x86 platform, not tested) as well (or just
reserve EBX for use for something else if you need it). Otherwise, yes.
It's lousy with conditionals, but it leaves almost everything the way it
found it if you don't enable them. I'd say it might come in handy if we run
into an x86 platform which doesn't let you use a segment register for TLS
and doesn't have quite as conveniently hijackable an exception-handling
mechanism as windows does, but it doesn't seem quite likely at this point.
> Also: at one point you pursued hanging TLS data onto the exception
> handler chain. I take that this is no longer on the agenda?
Actually, I'm thinking I might work up a tree with that approach later this
week, just to see how it goes. Certainly would be a smaller patch, due to
not having to move everything away from EBX. Basic impact would be most of
src/compiler/x86/cell.lisp, a touch in src/compiler/x86/nlx.lisp, covering
the FIXME in uwp-seh-handler or whatever it's called in
src/assembly/x86/assem-rtns.lisp, src/compiler/generic/objdef.lisp, and, of
course, src/runtime/x86-assem.S, instead of most of what's covered by
#!+x86-two-arg-passing-regs, #!+x86-reserve-ebx and #!+x86-ebx-threads now.
Wouldn't work on Linux, though, which would make -testing- it a little more
of a pain, and is part of why I did it this way first (I already had most of
the ebx-threads stuff working with an older SBCL).
> Cheers,
>
> -- Nikodemus
--Alastair Bridgewater

Alastair Bridgewater wrote:
> At http://www.lisphacker.com/temp/wthread-combined-1a.diff is a patch
> containing some initial Win32 thread hacking.
Many thanks!
Can you adapt a patch for the version >=1.0.4.3 (interrupt.c has changed)?
Thanks once again!
--
WBR, Yaroslav Kavenchuk.