Marko Kocić <marko.kocic@...> writes:
> I've been using your (and Dmitry) fork built from sources for some
> time, and didn't found any major problem so far.
> What is the status right now? Is it mature enough to be merged to sbcl
> main, at least as experimental feature?
As of `my' SBCL tree (see
http://www.siftsoft.com/forknews.html for details), there are some
problems with its integration in its current state. The main problem is
that I don't normally check non-win32 builds for my commits, so they are
probably broken (not fatally and deeply broken, though -- it should be
more like a forgotten ifdef here and there). I've gone to some length
separating safepoint-based code from signal-based one (and, on the other
hand, making Lisp-level thread interrupt handling more uniform across
platfroms), so the overall situation, in my impression, is not worse
(may be even better) than some months ago.
Supporting _non-threaded_ windows builds alongside threaded ones is not
easy; in my codebase it's currently broken, and more deeply than
non-win32 builds are. I wonder if it's worthy at all of the required
maintainance effort; the only thing we gain from non-threaded build on
win32 is faster access to dynamic variables (on some other platforms
going unithreaded can reduce dependencies, improve portability etc., but
not on Windows, as far as I can see).
I have a couple of local goals to complete before I turn to integration
(1) X86-64 threaded build for Windows (turned out to be surprisingly
easy; interruptions and callbacks are the only major things currently
(2) Another planned simplification of inter-thread signalling in
safepoint-based builds (incl. reimplementing asymmetric thread
synchronization in an obviously-correct way, not an obscure
X86-memory-model-bound thing that I have now).
I would appreciate anyone's help on cleanup, integration, separating
unacceptable things out, etc.., 'cause I'm not good at those things at
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia