Re: CVS commit: pkgsrc/devel/boehm-gc

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Fri, 02 May 2014 10:19:40 -0400
Greg Troxel <gdt%ir.bbn.com@localhost> wrote:

> So (assuming lots of work that hasn't happened yet happens and packages
> can choose threaded or not libgc with no difficulty), would you set ecl
> to be threaded by default?  It seems like there is a bug, but that at
> least for your case you find it better to have threads and avoid the
> bug.

If boehm-gc was more stable, and ECL no longer had stdio/rwlocks issues
with it, definitely, I'd suggest that threads be enabled by default for
ECL in the future (I'm not its pkgsrc maintainer, but would discuss it
with Asau); and we'd not need an eventual nothreads libgc version at
all.

Unfortunately, to avoid boehm-gc+ECL+threads bugs requires some
effort, and avoidance of third party libraries (Lisp and C/C++) which
may use stdio or rwlocks.  As an example, various libraries such as
libgd, libpq, libpcap, include as part of their API functions dealing
with stdio FILE handles, or internally using stdio.  These would affect
stability when used by ECL, or in cases where ECL would be embedded in
applications using such to provide "user scripting".

Background for ECL and NetBSD:

There are other good Lisp implementations which work on NetBSD (i.e.
CLisp and SBCL), but ECL is one which both achieves decent performance
(CLisp is interpreted) and which supports threads on many operating
systems (CLisp threads are experimental, SBCL only supports threads on
a few OSs, excluding NetBSD), and ECL is among the rare implementations
producing OS-friendly dynamic objects.  ECL compiles to C, which means
that it's easy to access functionality from the OS, libc and various
other libraries (via Foreign Functions Interface and (generation or
liberal use of) inline C).

Advantages of threads with ECL:

Although threads weren't part of the Lisp standard, it's very useful,
and dynamic variable bindings provide natural and easy TLS on
implementations which support threads.  In an interactive language with
a GC heap, using threads is more easily justifiable, when using
fork/processes requires more resources because of the heap size, more
complex IPC interaction and more use of FFI.
-- 
Matt