Andrew Clayton

> > Yeah, `OSError` would make more sense here... > > But then we'd have to flow `errno` through... > > You mean, to flow the error all the way...

@gourav-kandoria Was there an open issue about this?

Hi @gourav-kandoria Yeah, even though I said that, I'm not sure it's the right thing to do... Do you have some reproducer for this issue? I've been trying to myself,...

Hmm, I'd never heard of Server-Sent events before, even though they pre-date WebSockets... But, yes, I can reproduce this with the above application + curl(1). Thanks. An interesting observation is...

Certainly don't be surprised that debugging can change the behaviour of the program...

I think we need to step back for a minute as there may be a more fundamental issue here. With a WebSocket (strace(1)ing the Python app) ``` epoll_wait(12,

> ... not when client connection is actually closed. This is the bit we need to fix first, then the other bit may not even be an issue...

Just some notes... The message (`NXT_PORT_MSG_WEBSOCKET_LAST`) that notifies about the websocket disconnect is sent from `nxt_http_websocket_error_handler()` In the router process when closing a WebSocket ``` [pid 36046] epoll_wait(17, read_handler, 956...

When using a WebSocket we get (after Ctrl-C'ing the client) ``` (gdb) bt #0 nxt_epoll_block_read (engine=0x1728050, ev=0x7f9d740028e0) at src/nxt_epoll_engine.c:512 #1 0x000000000043b5dd in nxt_conn_io_read (task=task@entry=0x7f9d740039e0, obj=0x7f9d740028e0, data=0x7f9d74003d00) at src/nxt_conn_read.c:97 #2 0x0000000000413f97...

> makes sense. I just want to understand. Why it won't be okay. If at the time of writing back to socket. we notify app of disconnection. I get that,...