Porting sbcl to DragonFly

[John Marino]

On 3/30/2013 06:16, vasily postnicov wrote:
> Hello! I started porting SBCL to DragonFlyBSD. Previous (and only)
> attempt was
> http://leaf.dragonflybsd.org/mailarchive/users/2006-05/msg00108.html as
> far as I know. Google gives no more info on "sbcl on dragonfly" except
> this link.
>
> So I forked sbcl/sbcl repo from github a while ago and added support for
> DragonFly on x86-64 platform (with multithreading support). I even build
> stumpwm with sbcl and tried hunchentoot web server. Hunchentoot can
> handle 100 connections/second. This rate is almost its limit with
> one-thread-per-connection model.
>
> Link to repo:
> https://github.com/shamazmazum/sbcl-dragonfly
>
> There is a problem nevertheless: use of symbol-value-in-thread in
> sb-concurrency tests causes sbcl to crash (not to ldb, but crash
> completely!).
>
> So I have some questions:
> 1. src/runtime/Config.x86-64-freebsd states that we must use 1:1
> threading not m:n threading and uses lthr for that purpose. It seems
> that there isn't lthr in dragonfly, only lpthread is present. Should I
> use it? Is 1:1 threading supported? (It seems to work with lpthread anyway).
> 2. SBCL uses GCC TLS with (and only with) FreeBSD. I heard something
> about lack of "native" TLS in FreeBSD. Is it true? Is TLS present on
> DragonFly?
> 3. Can I build and install x86 environment and virtual kernel on x86-64
> machine? I prefer not to use VirtualBox if there is possibility to use
> vkernel. This is needed to port SBCL to x86 too.
>
> Sorry for possibly stupid questions, I am new both to DragonFlyBSD and
> SBCL internals.
>
> Any help of SBCL/Common Lisp hackers would be appreciated. I have really
> no idea how to fix sb-concurrency right now.

Actually, there have been at least two other attempts to support SBCL. 
Mine (http://leaf.dragonflybsd.org/~marino/ 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