From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: New patch for server sockets and datagram (UDP) support. Date: Thu, 7 Mar 2002 18:32:32 +0100 Message-ID: <200203071732.SAA17748@xaital.online-marketwatch.com> References: <5xwux64cxe.fsf@kfs2.cua.dk> <5xg03pyyo3.fsf@kfs2.cua.dk> <5xadtvuodz.fsf@kfs2.cua.dk> <200202280408.g1S48QG19264@aztec.santafe.edu> <5xvgchkui4.fsf@kfs2.cua.dk> <200203012123.g21LNvS20494@aztec.santafe.edu> <5xofi1p7cz.fsf_-_@kfs2.cua.dk> <5xg03cprxi.fsf@kfs2.cua.dk> <200203071518.QAA17238@xaital.online-marketwatch.com> <5xvgc8nyw0.fsf@kfs2.cua.dk> Reply-To: Helmut Eller NNTP-Posting-Host: quimby.gnus.org X-Trace: quimby.gnus.org 1015567766 28508 80.91.224.244 (8 Mar 2002 06:09:26 GMT) X-Complaints-To: usenet@quimby.gnus.org NNTP-Posting-Date: 8 Mar 2002 06:09:26 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16jDZG-0007PK-00 for ; Fri, 08 Mar 2002 07:09:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16j1lT-0007wB-00; Thu, 07 Mar 2002 12:33:15 -0500 Original-Received: from 212186011228.11.tuwien.teleweb.at ([212.186.11.228] helo=xaital.online-marketwatch.com) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16j1kr-0007gC-00 for ; Thu, 07 Mar 2002 12:32:37 -0500 Original-Received: (from helmut@localhost) by xaital.online-marketwatch.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id SAA17748; Thu, 7 Mar 2002 18:32:32 +0100 X-Authentication-Warning: xaital.online-marketwatch.com: helmut set sender to e9626484@stud3.tuwien.ac.at using -f Original-To: no-spam@cua.dk In-reply-to: <5xvgc8nyw0.fsf@kfs2.cua.dk> (no-spam@cua.dk) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1789 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1789 no-spam@cua.dk (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. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel