Re: Features that can only be provided by the implementation?

Peter Seibel wrote:
So folks have been discussing the desirability of having a way to
change "Common Lisp" a lot lately. And other folks point out that
many, or even most, changes that folks want could be built *in* Common
Lisp. But not all. So my question is, what features that you think
might usefully be available to you in a Common Lisp environment have
to be provided by the CL implementation itself. With the help of a few
folks on #lisp I've got this list so far:

- multithreading

I wouldn't necessarily care to have complete multithreading support.
The important thing would be for the Lisp implementation to be
thread-safe and thread-aware where it needs to be. The actual support
for creating and synchronizing threads could be left to the foreign
function interface. It's too platform-specific, and doesn't belong in
the language. You want to avoid the Java disease.

For instance, on Win32, I'd use critical sections and events, which are
different from POSIX mutexes and condition variables. There are lots of
other differences. Structured exception handling versus POSIX signals
and cleanup handlers, thread cancelation, thread-specific storage
cleanup with destructors, etc.

If you go too far in wrapping the platform, you basically create a new
platform which has a different set of inefficiencies and pathologies on
every underlying platform that it's ported to. You either get a crappy
subset of all of their capabilities that you have to program against,
or else you get some deluxe interfaces with all the features, half of
which are emulated on each platform (and it's a different half on each
platform).

Here is an example of such a thing: Windows sockets and select(). The
fd_set on Win32 is implemented as an unordered array of handles rather
than a bitmask. This has a number of implications:

- the first argument to select is unnecessary (the number of
descriptors to poll) since the fd_set knows how many descriptors are in
its vector. Some Win32 code leaves that argument it as zero and breaks
when ported to "real" sockets.

- The FD_ISSET macro actually performs a linear search through the
array instead of directly accessing the bit.

- the "struct timeval" timeout isn't passed into the kernel directly,
but has to be recalculated into some other kind of time, like probably
the number of milliseconds to wait. In UNIX-like systems, it would go
right down into the system call: a struct timeval is known between
kernel and userland.

So basically, the intended design of select() is badly emulated for the
sake of keeping the interface compatible, while coupling it to a
different underlying kernel interface on which polling is done using
arrays of handles. This could be identified as a case of abstraction
inversion, because the abstracting is done at an inappropriately low
level.

So what I do on Windows sockets is to do something completely different
anyway. In a highly efficient server, I'd use IO completion ports. In
client code, I'd just crack open the fd_set and iterate it myself,
inverting the logic: rather than testing using FD_SET, just directly
process the descriptors placed in the array, violating the
encapsulation within an #ifdef WIN32 block of code. Or just use the
WSA*() functions.

Often it's better to just rewrite a high level chunk of application
code rather than to keep it the same and coerce the the dumber, lower
pieces into behaving the same way.

Any others? (I'm not counting things that could be provided using an
FFI, such as an interface to sockets.)

And, more importantly, to /platform-specific/ sockets (etc.) that let
you program properly for that platform.

.

Relevant Pages

  • Re: network programming
    ... A network stack is an OS thing. ... The OS has a defined interface for file systems, and so it does for the ... (because there's no standard mapping between sockets and a Lisp API), ... Lisp is a jungle ...
    (comp.lang.lisp)
  • Re: SSL Socket
    ... > SSL support is a catalog element in Platform Builder. ... >>> interface and free, too? ... use it with standard managed sockets interfaces. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: cl-sockets, Google, Lisp-NYC, and The Savages of c.l.l
    ... > the nine Summer of Code projects Google sponsored through Lisp ... this common networking API for Common Lisp. ... Of the sockets functions that I consider essential, ... I assume that in "real" Lisp networking APIs, stream sockets can be ...
    (comp.lang.lisp)
  • Re: Socket benchmark?
    ... I was hoping to find a standard Lisp ... Petter> benchmark, presumably a parallel application using sockets, and see ... program in one or more Common Lisp implementations. ...
    (comp.lang.lisp)
  • Re: [Newbie]Seeking help with the choice of LISP implementation
    ... > preferred development platform is MSWindows/Intel ... which Lisp on which platform(s) do best). ... AllegroCL and Lispworks are available as trial editions. ...
    (comp.lang.lisp)
Loading