-
Notifications
You must be signed in to change notification settings - Fork 379
[Language] Networking primitives
I (@abailly) have ported naively Idris1 networking primitive support to Idris2 in order to provide basic socket-level networking capabilities to Idris2 programs. I quickly stumbled upon an issue whereby the server was blocked in recv()
ing messages from clients. Thanks to Steven Shaw's superhuman debugging powers, he discovered that deep inside Chez's FFI handling, there were calls to Slock_object(code)
: It prevented the code to be changed while executing a FFI thunk. As the server's main thread was blocked in accept()
call while the client handling threads was blocked in recv()
call, this basically deadlocked the server as soon as a client tried to connect to it. The (tactical) solution to this problem is to wrap each potentially blocking call into a pair of Sdeactivate_thread()
/Sactivate_thread()
calls.
Of course, the issue is Chez-specific which immediately begs several questions:
- Can Idris2 provide networking primitives that can reasonably be consistent across backends?
- If not, as I think is the case, what should we do?
- Does it even make sense in 2020 to provide blocking networking primitives as basically everyone is moving towards asynchronous I/O?
- https://idris2.readthedocs.io/en/latest/ffi/ffi.html
- https://github.com/cisco/ChezScheme/issues/265
- https://github.com/becls/swish
- https://github.com/evilbinary/scheme-lib — lots of dependencies OpenGL etc. etc.
- https://github.com/cisco/ChezScheme/issues/64#issuecomment-223741857
- https://github.com/cisco/ChezScheme/issues/71