<div dir="ltr"><div class="gmail_extra"><pre>> Actually, there have been at least two other attempts to support SBCL. 
> Mine (<a href="http://leaf.dragonflybsd.org/%7Emarino/">http://leaf.dragonflybsd.org/~marino/</a> see sbcl.tar.bz2 
> 23-dec-2011) and profmakx (I think it was him).  I believe he was 
> actually successful, but the patches were never imported into pkgsrc.  I 
> don't remember the exact details.  If this is true, then the logic 
> starting point is those patches although they are for an older release now.

> The long term solution is to get your/these patches into the upstream 
> codebase so no patches are required.

> 1. use pthread
> 2. TLS is present on DragonFly.  It's the reason version 2.0 was 
> released inside of version 1.14 (I think).  Anyway, DragonFly has had 
> TLS for many years now.
> 3. I think the only think you do with a x86-64 machine with regards to 
> i386 is to set up a bootloader and install DragonFly twice on it (32 and 
> 64 bit versions).  It is still not possible to run 32-bit binaries on 
> i386 on DragonFly, and I doubt it will ever be possible.

> So thanks on the initiative and I really think the next step is to hear 
> from profmakx (TBC) because I was under the impression all the issues 
> were solved.  Obviously my attempt didn't get all the way.

> John
</pre>


    <hr>> (<a href="http://leaf.dragonflybsd.org/%7Emarino/">http://leaf.dragonflybsd.org/~marino/</a> see <a href="http://sbcl.tar.bz">sbcl.tar.bz</a>)<br><br></div><div class="gmail_extra">Interesting, thanks. But has it threads and FPU exceptions handler on x86-64? (Handlers can be installed by defining X86_64_SIGFPE_FIXUP like it is done in FreeBSD code). You can check it by evaluating (/ 6.0 0.0). If you can see 'division-by-zero condition in debugger, it is installed.<br>
<br>> and profmakx (I think it was him)<br><br></div><div class="gmail_extra">All I can find is <a href="http://leaf.dragonflybsd.org/~profmakx/sbcl/crash/">http://leaf.dragonflybsd.org/~profmakx/sbcl/crash/</a><br></div>
<div class="gmail_extra">There is lib/ directory in archive, which contains nothing of interest.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I am still concerned about sb-concurrency's symbol-value-in-thread.3 test . It always causes sbcl to crash and always in different fashion (sometimes it just prints "Illegal instruction" and crashes, sometimes sbcl debugger is invoked with "The integrity of this image is possibly compromised" message and sometimes there are "[diagnostic] cache_lock: blocked on 0xffffffe00653eac8 sbcl.core" kernel messages). Definitely, something is wrong with multithreading, but real tasks (like hunchentoot) work well.<br>
<br></div><div class="gmail_extra">By the way, there is implementation of :sb-futex feature in sbcl for FreeBSD (but it is not enabled by default). It uses umtx_wait and umtx_wake functions for implementation of mutexes. As I understand it, DFBSD analogues are umtx_sleep and umtx_wakeup.<br>
<br></div><div class="gmail_extra">SBCL checks if return code of umtx_wait is 0, ETIMEDOUT, EINTR or any other value (see src/runtime/bsd-os.c, src/code/target-thread.lisp).<br><br></div><div class="gmail_extra">According to man umtx in DragonFly, umtx_sleep returns 0 or -1 and sets errno to EBUSY, EWOULDBLOCK, EINTR, EINVAL.<br>
<br></div><div class="gmail_extra">So what is ETIMEDOUT and why umtx_sleep does not return it?<br> </div></div>