Hi,
I’m glad to release usocket 0.8, next major release since 0.7.9.
[Changes in 0.8]
* New backend (experimental): IOlib. (Push :USOCKET-IOLIB to *FEATURES* to enable this feature) * New feature: Optimized WAIT-FOR-INPUT for single-socket case (one-time consing) * New feature: Exported host-to-hostname (#42) * Bugfix: [SBCL] more robust/thread-safe WAIT-FOR-INPUT-INTERNAL
[Downloads]
it should appear in Quicklisp’s "Feb 2019” dist updates, or can be downloaded here:
https://common-lisp.net/project/usocket/releases/usocket-0.8.tar.gz
or from GitHub:
https://github.com/usocket/usocket/releases/tag/v0.8
[Extra notes]
usocket's networking functionalities are essentially based on the networking APIs provided by each supported Common Lisp platforms. There’re pros and cons:
Pros: 1. the correctness of usocket’s API functions is based on the correctness of underlying CL platforms (which is usually reliable) 2. no dependency on dynamic loaded DLLs (with minor uses of FFIs if it goes beyond the features provided by underlying platforms, e.g. UDP on LispWorks)
Cons: 1. the behavior of usocket API is not always consistent across all supported CL platforms. 2. complex FFI-based coding at usocket side introduces potential bugs whenever it goes beyond the features provided by CL platforms. 3. C constants in BSD socket API must be defined as literal numbers for each tested OSes; sometimes these values are wrong for an arbitrary new unsupported *nix platform. 4. backend code for each supported CL platforms (sometimes even for each OSes) must be maintained separately, which brings extra inconsistencies.
I’ve been working for a long time on a new usocket backend: IOlib [1]. IOlib is a robust, feature-rich networking library based on CFFI and “libfixposix” library, and it’s behavior-consistent across all supported platforms. If you can correctly (which is not easy!) load IOlib in your working CL platforms of your working OS platform, e.g. SBCL/LispWorks on Linux/Mac, then it’s possible to use IOlib to do the actual networking work for usocket. And usocket’s WAIT-FOR-INPUT will now use Linux epoll() (or BSD/Mac kqueue()) to do the I/O multiplexing!! To enable this feature, just push a new feature keyword before loading usocket:
(pushnew :usocket-iolib *features*) (asdf:load-system :usocket)
To go back to the traditional backend, just restart your CL platform and load usocket normally without :usocket-iolib staying in *features*.
What’s more interesting is the ability to dynamically “switch” backends without restarting the CL platform:
(asdf:load-system :usocket) ;; this loads usocket with traditional backend ... (pushnew :usocket-iolib *features*) (asdf:load-system :usocket :force t) ;; this reloads usocket with IOlib backend
I didn’t actually test the other direction, but in theory if :usocket-iolib gets removed from *features* and you call (asdf:load-system :usocket :force t) again, usocket will go back to the traditional backend.
Currently there’re still many bugs in the IOlib backend, e.g. WAIT-FOR-INPUT doesn’t work quite properly, although all needed coding seems to be there. Thus please use with cautions, and I’ll continue fixing the IOlib backend in later updates.
Regards,
Chun Tian