Question: If a socket closes, and unbind is called, is outbound queue data discarded (note that close_connection hasn''t been called)? Also is a ''panic'' way to stop EM to kill the thread associated with it? Oh the only thought I had with regard to EM efficiency would be that it would be nice to, when it does a ''tick'' to queue all incoming data, per connection (an incoming_queue) so that while processing they can each get more. That would be nice. Maybe in future versions :) Kind regards. -Roger
On Nov 17, 2007 12:29 AM, Roger Pack <rogerpack2005 at gmail.com> wrote:> Question: > If a socket closes, and unbind is called, is outbound queue data > discarded (note that close_connection hasn''t been called)?A socket can obviously close in ways not caused by your code intentionally closing it. In all cases, #unbind is called by the reactor so your code can clean up what it has to. The connection is always dead and gone by the time #unbind is called, and the outbound queue (if any) has been discarded.> > Also is a ''panic'' way to stop EM to kill the thread associated with it? >I don''t understand the need to panic-stop the reactor. The only way for it ever to block (absent a bug inside the reactor) is if you write an event callback that blocks.> Oh the only thought I had with regard to EM efficiency would be that > it would be nice to, when it does a ''tick'' to queue all incoming data, > per connection (an incoming_queue) so that while processing they can > each get more. That would be nice. Maybe in future versions :)It already does this. Or more precisely, the kernel does it. Generally speaking, you don''t want to pull more data off the network than your program can handle expeditiously, for several different reasons.
On 11/16/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> On Nov 17, 2007 12:29 AM, Roger Pack <rogerpack2005 at gmail.com> wrote: > > Question: > > If a socket closes, and unbind is called, is outbound queue data > > discarded (note that close_connection hasn''t been called)? > > A socket can obviously close in ways not caused by your code > intentionally closing it. In all cases, #unbind is called by the > reactor so your code can clean up what it has to. The connection is > always dead and gone by the time #unbind is called, and the outbound > queue (if any) has been discarded.This may be more of a TCP socket thing, but is unbind only called when both sides have closed the TCP connection? Like I could call close_connection and then in extreme cases receive_data could still be called, but I can rely on unbind to reliably be the last call by the reactor--is that right? I only say this because I have had cases where I will close a TCP connection with a peer, and then like 20 seconds later they will send me some information then close their side of the connection. Their bug, I agree. But EM would handle this by only calling unbind after they close the connection, as well?> > > > Also is a ''panic'' way to stop EM to kill the thread associated with it? > > > I don''t understand the need to panic-stop the reactor. The only way > for it ever to block (absent a bug inside the reactor) is if you write > an event callback that blocks.Ahh. So in reality existing connections will most likely close ''quickly'' , once each connections peers also also close their connection--is that right? Thanks for your help. I just love knowing internals so nothing surprises me.
> I don''t understand the need to panic-stop the reactor. The only way > for it ever to block (absent a bug inside the reactor) is if you write > an event callback that blocks.The only reason I can think of is to shut off existing timers/connections ''immediately'' in some other thread, so you can restart EM. In which case it might be nice to have a call that ''defers'' a proc until EM actually shuts down, or blocks until all connections do. Then again maybe not :)> It already does this. Or more precisely, the kernel does it. Generally > speaking, you don''t want to pull more data off the network than your > program can handle expeditiously, for several different reasons.Works for me. Thanks!
On Nov 19, 2007 12:04 PM, Roger Pack <rogerpack2005 at gmail.com> wrote: > This may be more of a TCP socket thing, but is unbind only called when> both sides have closed the TCP connection? Like I could call > close_connection and then in extreme cases receive_data could still be > called, but I can rely on unbind to reliably be the last call by the > reactor--is that right? >I hate to give a slippery answer but unbind will reliably be called when the local side of a TCP connection has closed, or the reactor has detected either a close or a reset by the remote peer. This is slippery because there are several (unusual) cases where a remote peer can close a connection and the local peer doesn''t find out about it. These are network and TCP issues, not EM issues.> I only say this because I have had cases where I will close a TCP > connection with a peer, and then like 20 seconds later they will send > me some information then close their side of the connection. Their > bug, I agree. But EM would handle this by only calling unbind after > they close the connection, as well?It sounds like you want to do a "half-close," in which you signal that you won''t be sending any more data but you want to keep receiving data from the other end. EM doesn''t currently support this.> > > > > > > Also is a ''panic'' way to stop EM to kill the thread associated with it? > > > > > I don''t understand the need to panic-stop the reactor. The only way > > for it ever to block (absent a bug inside the reactor) is if you write > > an event callback that blocks. > > Ahh. So in reality existing connections will most likely close > ''quickly'' , once each connections peers also also close their > connection--is that right?Yes.
> I hate to give a slippery answer but unbind will reliably be called > when the local side of a TCP connection has closed, or the reactor has > detected either a close or a reset by the remote peer. > > This is slippery because there are several (unusual) cases where a > remote peer can close a connection and the local peer doesn''t find out > about it. These are network and TCP issues, not EM issues.Thanks for the quick answer! -Roger