From: Todd S. <ts...@op...> - 2002-05-28 16:20:37
|
Sam Steingold <sd...@gn...> writes: > > What about the idea of having a SOCKET-CONNECT% didn't you like? > > KISS - keep it simple. > > first, this is not really necessary. > if we really will introduce the "half-baked streams" (i.e., streams that > will start any i/o operation with a connect() syscall), I think you may have misunderstood again. They wouldn't start any i/o with a connect call. The connect call would already have been made, but in non-blocking mode. If you were to try to use the socket/stream without waiting (via SOCKET-STATUS) for the connect to finish, then it would just block at that point. There'd be no need to modify any of the current read/write paths. > they can be > created when the timeout is 0 (i.e. when otherwise we are guaranteed to > get an error). This would work for me. > second, I am not sure these "half-baked streams" are a good isea. > what do you need them for? I've already explained several times, but I'll try again. Imagine you're writing a proxy server. You accept connections from clients, and in the process of servicing them, you have to open connections to the resources they're requesting. Unless you consider it acceptable for your proxy to be totally non-responsive for large periods of time, you've got to have a non-blocking connect. The only representation in clisp for a socket connection is a socket-stream. Therefore, you need a non-blocking way of getting a socket-stream which you can then use with socket-status. Is that clear enough? > > I don't suppose it makes sense to re-suggest the stuff in: > > http://www.geocrawler.com/archives/3/1124/2002/1/100/7517822/ does it? > > here is the problem. > I _know_ what you want: you want, basically, bindings/linuxlibc6 in > CLISP at all times on all platforms (this is actually what I wanted when > I added --with-export-syscalls). Therefore anything short of that will > not satisfy you, and a lot of that will not be portable (even across > unixes) and will not work too well with the traditional Lisp paradigms, Please stop assuming you know what I want. What I'm saying in that email is that I want _sockets_, not all of linuxlibc6, on all platforms. Are there any clisp-supported platforms that don't support, say, UDP sockets? If not, why not make them standard in clisp? Why should people be forced to resort to FFI? I think there is a basic set of socket functionality which is available on all platforms (socket, bind, listen, accept, connect, recvfrom, sendto, e.g.). And that providing that, and then building higher level stuff on top of it would provide people with far more functionality and options than they currently have. Do you disagree with the feasability of that? If so, are there specific problems you know of? > > Sam already shot that down, but it's another way of dealing with this, > > as well as providing UDP sockets, unix domain sockets, etc. To tell > > the truth, I've already implemented most of that locally. It needs > > some refinement, but works just fine. > > good. > first, wrap it into `#ifdef EXPORT_SYSCALLS'. I think #ifdef FULL_SOCKETS or something would be more appropriate. > second, please do try to go a step up from bindings/linuxlibc6: a lot > of stuff here can be unified in one function (e.g., FILE-STAT unifies > lstat() and fstat()). As I said, this is a non-issue for me. > third, provide a way to get back into the Lisp world, i.e., something > like `sys:make-fd-stream' in CMUCL to convert a socket to a stream. Yes, this is really the crux of the problem. There's currently no way to get back into the normal lisp world. What I did for now was to expose make_socket_stream as MAKE-SOCKET-STREAM% (should be %MAKE...). If you agree that (or something similar) is necessary, and if you agree that the basic socket functionality can be exposed portably (though perhaps you don't), then you're 95% of the way to what I was suggesting in that email. At least, maybe you understand where I'm coming from now? E.g., given the above, I wouldn't care about clisp not providing the non-blocking connect, because I could easily add it myself at the lisp layer. And the same would be true of lots of other socket functionality. Todd |