[LispM] BSD style socket interface?

[Chris Hanson]

On Dec 26, 2017, at 11:31 AM, Christopher Stacy <cstacy at csail.mit.edu> wrote:
> 
> The program you're trying to run was apparently written for a specific
> operating system (Unix), and depends on a library that merely offers
> compatibility betweeb slightly different versions of Unix.
> 
> The Lisp Machine is in no way Unix and does not support Unix-like APIs.

I wouldn’t necessarily call usocket a library offering compatibility between different versions of Unix. The usocket library offers an abstract network interface that follows a similar design to BSD sockets, and can therefore be backed by BSD sockets easily, but doesn’t have to be.

Furthermore, BSD sockets aren’t themselves purely a Unix abstraction any more than C standard I/O is: Sure they came from Unix, but they’re available on other platforms that very much aren’t Unix too like classic Mac OS, classic Windows, and Windows NT derivatives. (And Amiga, and RISC OS, and…)

> I think your estimation that creating the Sockets API would take a
> week or two sounds about right.  It would take one day, followed by
> debugging and testing the rest of the week.  There could be bugs
> that wouldn't show up for a long time due to timing issues;
> that's how network code works (or doesn't).

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.

I suspect writing a usocket backend for Genera networking isn’t that tough a task, given the overall completeness of Genera APIs. (Just like I expect implementing an Open Transport or MacTCP back-end for MCL on the classic Mac OS shouldn’t be too tough.)

> There are probably other interesting programs besides the one that
> you want to run that rely on usocket.  The other compatibility layer
> that I would wonder about is the multiprocessing interface.

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.

  — Chris