[Sbcl-devel] SBCL+Threads+Win32 [experimental]
Anton Kovalenko
Hello dear SBCL developers,
Having succumbed to the temptation of trying my weird ideas on threaded
sbcl-win32 (so now I don't know for sure when I'm able to return on the
way to code cleanup and integration),
I decided, at least, to provide anyone interested
(1) with the description of those aspects of my patches that are stable
enough to describe them sensibly:
* http://www.siftsoft.com/inprogress/forknews.html
(2) with a `bleeding edge' binary to try out how this code (pretends to)
work:
* http://www.siftsoft.com/inprogress/sbcl-1.0.45.XIII.252.msi
[Windows'2000 or above]
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
Marko Kocić
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?
Regards,
Marko
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
Anton Kovalenko
> 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/inprogress/sbcl-notes.html and
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
tasks:
(1) X86-64 threaded build for Windows (turned out to be surprisingly
easy; interruptions and callbacks are the only major things currently
missing).
(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
all.
--
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia
------------------------------------------------------------------------------
Nikodemus Siivola
> 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 don't think having a unithreaded Windows build is required, if
maintaining one is trouble some.
> I would appreciate anyone's help on cleanup, integration, separating
> unacceptable things out, etc.., 'cause I'm not good at those things at
> all.
I'm really disappointed at not having been able to look into
integration issues yet, despite having dropped hints to that effect
last autumn. Can't make any promises right now either, but... I'd
really like to find the time to look into it.
Cheers,
-- Nikodemus