#606 :write after :close

Reporter Daurnimator
Owner Nobody
Stars ★ (1)
  • Priority-Medium
  • Status-Accepted
  • Type-Defect
  1. Daurnimator on

    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

  2. Zash on

    Can you be more specific?

  3. Daurnimator on

    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 end toclose = true return false end ``` - 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`

  4. Zash on

    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.

New comment

Not published. Used for spam prevention and optional update notifications.