Re: New patch for server sockets and datagram (UDP) support.

[Helmut Eller]

address@hidden (Kim F. Storm) writes:

> > It's probably a pain to parse keyword arguments in C, but it frees you
> > from overloading positional arguments in an unnatural way.  It would
> > also be quite nice to use from Lisp.  Another advantage is that you
> > could add new arguments without much backward compatibility
> > restrictions.
> 
> It still has the problem of what to do with unknown arguments --
> but at least it will not trigger the debugger due to an incorrect
> number of arguments.

Raise an "invalid keyword" error.  That's the pain it was talking
about.

> >  I propose
> > to make gethostbyname and related functions available to Lisp.  IP
> > addresses could be represented by vectors of 4 bytes (it's a pity that
> > 32bit don't fit into a ELisp fixnum).
> >
> 
> Not that I object to this in general, but for what purpose? 

Because there is currently no way to get the IP address(es) of the
current host.  It MAY also simplify the C level implementation,
because you could require that e.g. the SERVICE argument is actually a
port number and not a string or a number; similar for the HOST
argument.

> > Yet another point: please, please, please make accept-connection a
> > separate function.  Then one could make a _blocking_ accept; also
> > accept with a timeout argument would be possible.
> 
> I understand that you want to serialize the connections.
> Why is it necessary to do that?  

It's probably not necessary in 95% of all uses, but it may be hard to
change later if you hardwire the current behavior.  And, about every
socket interface I have seen so far has a separate accept function.

Here is a somewhat artificial example.  I would like to control Emacs
from an external Common Lisp program.  I would also like to control
the Common Lisp program from Emacs.  Do to this I implemented a very
naive rpc mechanism: both sides send their commands via a socket
connection to the peer, the peer evals the command and sends the
result back to the client.  Now the problem: if the command include a
recursive/nested calls to caller, serialization is an issue.  The
cleanest thing is to accept exactly one connection at a time.  Of
course, it is not very hard to come up with different solution, but
accept-connection makes this particular use elegant and reliable.

> And you can start a timer to cancel the accept (by calling
> delete-process) if a connection hasn't been received.
> The sentinel can cancel (or restart) that timer if a
> connection is accepted.

Yes I could.  But a blocking accept is easier to use and more
reliable.

If you think a separate function is to much trouble, leave it out.

Helmut.