I keep hoping that #'GET-HOST-BY-NAME will be exported from USocket. In poking around trying to see how hard that would be, it looks to me like the only backend that doesn't currently support it is ECL. And, that backend only supports ECL under Windows as it is.
If I spend some time getting GET-HOSTS-BY-NAME working for ECL on Windows (and other systems), can we make GET-HOSTS-BY-NAME a non-optional feature of the backends and export GET-HOST-BY-NAME and some of its friends?
Also, I just looked through WAIT-FOR-INPUT trying to see the most efficient way that I can employ that function. It looks like if I used MAKE-WAIT-LIST, ADD-WAITER, and REMOVE-WAITER in my code, then I could pass the wait-list into WAIT-FOR-INPUT so it doesn't have to construct one itself. That'd be nice. All of those functions are exported, but WAIT-LIST-WAITERS is not. So, I would still need to either maintain a separate copy of the WAITERS for myself or use the :READY-ONLY option. Can we export WAIT-LIST-WAITERS?
On a similar note, even given the whole list of WAITERS, I still need to use the unexpected STATE function to get the waiting state of each socket. I'd propose adding a predicate that checks whether the state is :READ or :READ-WRITE. Or, we export STATE? Or some reader for that state? Or some predicate that returns true if the state is :READ?
I'll gladly work on the above and submit patches if there's consensus….
Thanks, Patrick
Hi Patrick
Thanks for your suggestion. I'll try to fix GET-HOST-BY-NAME for ECL to support non-Windows platforms soon.
I think it's reasonable to export more interfaces for WAIT-FOR-INPUT to make it more efficiency for advanced users, but some of exist symbols (i.e. STATE) may be too simple that it could be conflict with other packages or user application, therefore I'm thinking a prefix WFI- or just WAIT- for all these potential new exports. Do you have any suggestion?
Regards,
Chun Tian (binghe)
On 2013-04-05, at 3:20, Patrick Stein pat@nklein.com wrote:
I keep hoping that #'GET-HOST-BY-NAME will be exported from USocket. In poking around trying to see how hard that would be, it looks to me like the only backend that doesn't currently support it is ECL. And, that backend only supports ECL under Windows as it is.
If I spend some time getting GET-HOSTS-BY-NAME working for ECL on Windows (and other systems), can we make GET-HOSTS-BY-NAME a non-optional feature of the backends and export GET-HOST-BY-NAME and some of its friends?
Also, I just looked through WAIT-FOR-INPUT trying to see the most efficient way that I can employ that function. It looks like if I used MAKE-WAIT-LIST, ADD-WAITER, and REMOVE-WAITER in my code, then I could pass the wait-list into WAIT-FOR-INPUT so it doesn't have to construct one itself. That'd be nice. All of those functions are exported, but WAIT-LIST-WAITERS is not. So, I would still need to either maintain a separate copy of the WAITERS for myself or use the :READY-ONLY option. Can we export WAIT-LIST-WAITERS?
On a similar note, even given the whole list of WAITERS, I still need to use the unexpected STATE function to get the waiting state of each socket. I'd propose adding a predicate that checks whether the state is :READ or :READ-WRITE. Or, we export STATE? Or some reader for that state? Or some predicate that returns true if the state is :READ?
I'll gladly work on the above and submit patches if there's consensus….
Thanks, Patrick
usocket-devel mailing list usocket-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
On 2013-04-17, at 2:55 AM, Chun Tian (binghe) wrote:
I think it's reasonable to export more interfaces for WAIT-FOR-INPUT to make it more efficiency for advanced users, but some of exist symbols (i.e. STATE) may be too simple that it could be conflict with other packages or user application, therefore I'm thinking a prefix WFI- or just WAIT- for all these potential new exports. Do you have any suggestion?
To me, I think the most reasonable would be to export WAIT-LIST-WAITERS and a SOCKET-READABLE-P function that returns whether the state is :READ or not. Of course, it wouldn't be obvious that one has to WAIT-FOR-INPUT to make sure the SOCKET-READABLE-P is up-to-date. Another approach might be to have WAIT-FOR-INPUT take a function to call on the readable sockets. This would discourage anyone from disassociating the WAIT-FOR-INPUT and the READABLE state.
(labels ((handle-socket-input (socket) … do something …)) (wait-for-input my-wait-list :timeout 0 :ready-func #'handle-socket-input))
and inside WAIT-FOR-INPUT:
(when ready-func (dolist (sock (wait-list-waiters socket-or-sockets)) (when (eq (state sock) :read) (funcall ready-func sock)))
I could go either way….
I just noticed that each USOCKET instance tracks which WAIT-LIST (if any) it is part of. I wasn't expecting that. I was expecting to be able to keep several WAIT-LISTs around (which may overlap) and use different ones at different times. Hmmm. Of course, with a quick look, I'm not seeing how it's being used on the front-end in any way except in ADD-WAITER, REMOVE-WAITER, and REMOVE-ALL-WAITERS. Maybe it's used on the backend? I'll have to look closer.
Anyhow, you asked in the thread with Faré's patch if anyone would like to co-maintain. I'm pretty busy myself, but I wouldn't mind helping out. USOCKET is one of my favorite libs out there.
Thanks, Patrick
-
Chun Tian (binghe) -
Patrick Stein