Porting sbcl to DragonFly

[vasily postnicov]

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 <shamaz.mazum at gmail.com>

>
>
>
> 2013/4/21 Markus Pfeiffer <markus.pfeiffer at morphism.de>
>
>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20130424/205c7136/attachment-0002.html>