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
[1] https://common-lisp.net/project/iolib/
signature.asc
Description: Message signed with OpenPGP using GPGMail
