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 <[email protected]> wrote: > 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 > > -- ~JT
