I noticed that some modules (at least net.http.server) will call net.server's :write *after* they've called :close.
This seems like something that shouldn't happen
Can you be more specific?
Well I got a traceback from my custom net.server_cqueues; I had made it an error to `:write` to a `:close`d connection. Up the stack was net.http.server.
This behaviour (:write after :close) is generally an error condition:
- At the OS level, write() to a closed socket would be EBADF.
- In server_select it's would be an error (but only if the outgoing queue is empty; I think net.http.server gets luckily here):
if bufferqueuelen ~= 0 then -- Still not empty, so we'll try again later
if handler then
handler.write = nil -- ... but no further writing allowed
toclose = true
- In net.server_event it's a non-logged error (returns nil, err; but no one checks :write return values....): `if self.nowriting then return nil, "locked" end`
At least server_event will just return nil, "locked" currently (see #559).
Finding the cases where it attempts to write to closed handles and fixing those would be good but I don't think throwing a hard error is sensible.