[LispM] BSD style socket interface?

[Joe Marshall]

On Tue, Dec 26, 2017 at 10:08 PM, Chris Hanson <cmhanson at eschatologist.net>
wrote:

>  Network code isn’t inherently harder or different than other code that
> involves multiple processes.
>

I think it is indeed harder than non-networked multi-process code.  It is
relatively easy to arrange
synchronization points if all the hardware is local, but it can be fairly
expensive among distributed machines.
You try to avoid using them if possible, and it is much more important to
use completely asynchronous
algorithms in the main code paths.  Since even partial synchronization
(like memory "fences" to ensure that things
appear in the correct temporal order) can be expensive, you have to
consider out-of-order execution possibilities.
With local hardware, it is usually easy to get multiple processes to agree
as to what time it is and which direction it
is flowing.  It can be difficult to get networked machines to agree on the
time, and it can appear to behave oddly
if the networked machines get out of sync.

With local multi-processing, many useful operations can be guaranteed to
complete (e.g. reading a shared memory location)
in some way.  With a network, all operations involving network traffic can
fail to complete.  The result of any network
query can be "unknown as of yet".  It is difficult to abstract out this
behavior.  Higher level procedures will have to deal with
this low-level detail, and this is where mistakes happen.  Many bugs i've
seen in network code occurs because
the programmer has overlooked a situation where a network timeout might
occur.  It is easy to forget that a predicate
that returns a definitive yes or no could potentially fail to return a
value at all.

I just think that network code is a little bit more complicated than
non-networked, but multiple process code.

-- 
~jrm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </archives/lispm/attachments/20171227/107fc0e8/attachment.html>