Re: Sockets in Pharo CollaborActive Book
First, please don't assume that you have to change course just because we offered to help. If you are close to
having a major improvement, then it might be best to just power through it. If there are things holding you
up, we might be able to help there.
Using Alien concerns me a little, as the last time I checked, it was not available on Linux?? Failure to
support Linux would be a complete show-stopper for me. Regardless, I would like to see your code as I have
read some comments suggesting that Alien is cumbersome to use; you might show me that all is well. My
interest in Alien is primarily to support callbacks for numerical analysis. So far, I have been adding
functions to a shared library, which is easy enough, ultimately translates formulas using C++ (which is
better at it than Smalltalk), likely makes things go faster than they would with Smalltalk in the loop, but
is far from elegant. Until Alien exists on Linux, it does not exist :(
Back to sockets, if the current situation were to stand, for whatever reason, I would consider tackling the
problem using a plugin to get OS threads, and use them to achieve the non-blocking operation that is
essential for interactive software. In short, everything blocks its calling Smalltalk Process;
nothing blocks the entire image. Hopefully you recognize that a server listening with timeouts is
hideous design; just start and stop the server as needed, and it should be harmless to the image. If the
server is not harmless to the image, it needs to be fixed. Clients having timeouts isn't much better. If you
want to add helper methods with timeouts, who am I to tell others what to do, but we must not force timeouts on
clients because there is no correct answer to how long something should wait, so we should not look for one.
What we should do is make sure that we never block the entire image, and let people make their own decisions.
Why would I consider a plugin? In large part because there are hints that I would find examples to follow, and
because OpenSSL has a very cumbersome non-blocking interface, at least that was my impression of it. A
plugin that I would write would hopefully support TCP and OpenSSL sockets, and hopefully IrDA. Running
those things on OS threads and signaling semaphores in the image is likely to be simpler than working out
the details of non-blocking calls in the separate worlds - I think. I can understand why you are not
thrilled about creating a plugin.