Motivation

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.

Discussion

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?

References

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