[Pharo-project] Socket timeout terminates COG VM
jt at parspro.com
Mon Oct 10 17:28:12 EDT 2011
I agree. In my own networking code, my sockets handlers on both side
never timeout. I have a manager/monitor process that I use if I have
to kill them.
On Mon, Oct 10, 2011 at 17:18, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
> 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.
> From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John Toohey [jt at parspro.com]
> Sent: Monday, October 10, 2011 4:19 PM
> To: pharo-project at lists.gforge.inria.fr
> Subject: [Pharo-project] Socket timeout terminates COG VM
> 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)
More information about the Pharo-dev