Raymond Toy <[EMAIL PROTECTED]> writes: >>>>>> "Tim" == Tim Moore <[EMAIL PROTECTED]> writes: > Tim> At the least, I'm assuming we can steal Dan's SBCL work :) > > But I thought that was Linux- or x86-specific. Doesn't help me > out on Solaris. :-(
It's presently both Linux- _and_ x86-specific, but my hope is that it will not stay that way. Eventually I'll get to Alpha and/or PPC ports, at least. I'm avoiding pthreads (using clone() instead) because pthreads on Linux typically means LinuxThreads, and they do evil things with signals which (IMO) we really don't need to have done. If you have a platform where the Posix threading is usable, you can use that instead. (I know about the upcoming new 1:1 threads interface in Red Hat 8, but it requires "tomorrow's kernel and next Tuesday's glibc release" so I'm not going to worry about that just yet) Some kind of register is needed to point to thread-local storage (for per-thread symbol values). On x86 I'm using a segment register; ports to non-Linux x86 targets will need some interface to initialise segment selectors meaningfully a la modify_ldt -- but anything on which Wine runs probably has this already. On non-x86 ports a geenral-purpose register should be fine, but obviously they'll need to do their own thing for the various VOPs I've changed. GC will be fun. I'm hoping that the multiple regions support in gencgc (which isn't currently being used much) works and will allow multiple threads to cons at once without blocking each other. Not sure what to do about non-x86 ports there, but will worry about that some other time. -dan -- http://www.cliki.net/ - Link farm for free CL-on-Unix resources
