From: Alastair B. <nye...@li...> - 2007-03-25 19:10:19
|
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 |
From: Nikodemus S. <nik...@ra...> - 2007-03-26 07:47:10
|
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 |
From: Alastair B. <nye...@li...> - 2007-03-26 18:14:03
|
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 |
From: Yaroslav K. <kav...@je...> - 2007-03-27 09:22:23
|
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. |
From: Yaroslav K. <kav...@je...> - 2007-03-28 11:45:59
|
Alastair Bridgewater wrote: > At http://www.lisphacker.com/temp/wthread-combined-1a.diff is a patch > containing some initial Win32 thread hacking. Nice! Some found problems (it is one error more likely): gc.impure.lisp and threads.impure.lisp (from tests/) call LDB monitor: ldb> backtrace Backtrace: 0: Foreign fp = 0x159fb24, ra = 0x406783 1: Foreign fp = 0x159fb54, ra = 0x405897 2: Foreign fp = 0x159fb74, ra = 0x40be39 3: SB-KERNEL::GC-START-THE-WORLD ... slime is started, but any expression /* like (+ 1 1) */ call LDB monitor too; bordeaux-threads test call LDB monitor too ... Thanks! -- WBR, Yaroslav Kavenchuk. |