Good news. The problem is somethere inside schedule_thread_post_mortem. If you comment call of this function from undo_init_new_thread out, all will be good (with exception of some memory leaks, of course).
Last thing to do is to fix this bug. Inside src/runtime/thread.c you can find 3 different mechanisms of reclaiming resources/freeing memory left by dead threads. We must find at least one which works. You are welcome to help if you want :) 2013/4/22 vasily postnicov <[email protected]> > > > > 2013/4/21 Markus Pfeiffer <[email protected]> > >> Hi, >> >> On Sat, Apr 13, 2013 at 12:14:15AM +0400, vasily postnicov wrote: >> > I've started sourceforge project, where I put sbcl-1-1.6 patched for >> DragonFly. >> > I almost gave up fixing threads support, so it is switched off by now. >> > >> > Here is pkgsrc package (based on original lang/sbcl): >> > http://shamazmazum.users.sourceforge.net/sbcl.tar >> > >> > Can anyone upload it to DragonFly's pkgsrc tree? I can maintain this >> package >> > and send new versions on regular basis. >> >> Out of interest: What stops threads from working? Is it a DragonFly issue >> or >> is it just that SBCLs thread model is not easily ported? >> >> Markus >> > > Can't find it out. SBCL just crashes with 'Illegal instruction' inside > _umtx_wakeup_err (according to gdb). Moreover it crashes always in > unpredictable fashion. I tested hunchentoot web server. It can handle up to > 100 connections/second for a long time, but can also cause sbcl to crash > almost instantly. > > I build SBCL with ":sb-thread", ":sb-thread :sb-futex" and ":sb-thead > :sb-futex :sb-futex-pthread" features. It is all the same. >
