John, Let me see if I can turn you to the dark side :) Sockets should **never** timeout. Socket servers (distinct from server sockets) should listen for and accept connections until told to stop. Client sockets should assume the server will respond a"any minute now" until they are told to give up. Sockets should use events vs. polling (one exception is arguably if a socket function call is running on a separate OS thread). All socket calls should block the calling Process while other Process instances run and the image remains responsive - no one would ever run a socket call on the gui thread, right?
Harsh, I know, but it makes sense once you try it. Part of why I mention OS threads and blocking calls is that I would very much like to see us have in-image support for SSL, and OpenSSL is a nice way to do that. The OpenSSL non-blocking API is kinda scary, so blocking calls make a lot of sense. Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of John Toohey [[email protected]] Sent: Monday, October 10, 2011 4:19 PM To: [email protected] Subject: [Pharo-project] Socket timeout terminates COG VM Hi, I've had a problem since 1.0 with socket timeouts throwing exceptions and invoking the debugger in my headless images. I don't know why a socket timeout is considered exceptional, but I've gotten used to using VNC to log into the server and close the debuger windows. However, I've moved to COG and the latest one-click images, and now the error terminates the VM. My app is a standard Seaside server, using the streaming connector for Comet support. I've attached the PharoDebug.log. It would be appreciated if anyone could help me with this problem, as I'm at a loss where to even begin. Using Pharo1.3 #13298 on Lucid32 (Ubuntu) -- ~JT
