[LispM] BSD style socket interface?
Christopher Stacy
cstacy at csail.mit.edu
Tue Dec 26 23:02:21 PST 2017
On 12/27/2017 01:08 AM, Chris Hanson wrote:
>
> This is only how things happen with network code that isn’t written carefully with an understanding of both the API behaviors and the network protocols in play. Network code isn’t inherently harder or different than other code that involves multiple processes
Well, the thing is "an understanding" can be a mouthful. I have never
seen any
implementation of the TCP/IP stack in all the 36 years that did not have
bugs.
Some of which were not discovered for a very long time.
Just one of many examples:
https://tech.vijayp.ca/linux-kernel-bug-delivers-corrupt-tcp-ip-data-to-mesos-kubernetes-docker-containers-4986f88f7a19
That's just implementation bugs. Of course there have been serious bugs in
the design of TCP/IP itself, based on not "fully understanding" various
emergent
properties at all implementation and conceptual levels of the system.
> I suspect writing a usocket backend for Genera networking isn’t that tough a task, given the overall completeness of Genera APIs.
As I said, I think writing a Sockets interface for Genera is probably
just a few days.
It's been years since I looked at the Genera network code, but I mean,
how hard
could it be? It's basically just got to manage some intermediate
sockety objects
that implement some pretty fundamental operations that are already there
somewhere.
If I already had an Open Genera sitting in front of me to hack on, it
would probably
have already been done (for some value of "done") in the period since I
first replied.
I'm trying to get one set up on my laptop :)
> Indeed, the LispM process model is very different from the modern threading model assumed by packages like Bordeaux Threads, but I suspect that could also be implemented reasonably compatibly—at least in a situation where everything that needs to directly interoperate uses the Bordeaux Threads API.
>
It's a descendant of the CLIM compatibility library, so it would be be
coming full circle.
A glance at the documentation suggests to me that one big thing was to
reintroduce
"condition variables" so that you can hang on them, which is of course
something
that was in the original LispM scheduler (which idea from the ITS
scheduler on the PDP-10).
I think the variable binding semantics are the same (globals get bashed,
locals are in your
own stack-group) although this seems like it is necessarily a property
of the supported
Lisp implementations rather than the Bordeaux specification.
I'm actually a little surprised that nobody already implemented these
things for Genera.
I guess they were created just past the timepoint when there were even a
few people
actually using Genera at all. ASDF for example is conditionalized for
Genera as you know.
More information about the LispM
mailing list