calling C code // drivers

[Luke Gorrie]

"Vlad Dumitrescu" <vlad_dumitrescu@REDACTED> writes:

> Are there any specific reasons to use the current way of interfacing with C
> code (i.e. the drivers) as it is today opposed to another one? What are the
> arguments for not using a more direct way than today? What I have in mind is
> the fact that with Hipe Erlang functions are compiled to native code - in
> theory, I can't see any reason why one couldn't compile C code to look like
> Hipe generated one. Thus we could have everybody write their own BIFs!! :-)

CMUCL &co do this. You can just call any C function you like, even
from the shell. You can also cast certain types of arrays/strings to C
strings (char*) and so on. Thus they call select() etc directly from
Lisp and don't have C drivers.

Sounds nice. But there's a catch :-)

I read about an _extremely_ nasty bug just the other day. It relates
to a "write barrier" that their garbage collector uses. It uses the
mprotect() system call to mark pages of memory as read-only, then a
SIGSEGV handler to trap writes and allow them after recording the fact
that the page was modified. This lets the garbage collector keep track
of which objects have been modified since the last collection.

Trouble was, Lisp strings are sometimes passed as char* buffers to
system calls, and if that buffer's memory is read-only then the system
call can't write to it -- the SIGSEGV handler is inhibited. So your
reads will fail if the string you're using as a buffer has not been
modified since the last garbage collection, because it's in read-only
memory.

This suggests to me that there's something to be said for doing all
operating system interaction in a proper runtime system. :-) Certainly
I'm glad the code I'm responsible is written in Erlang.

Cheers,
Luke (pretending not to be responsible for some nasty C code too..)