Overview
Artifact ID: | 038e3056b1d9393afacbb9c4e950cff68341b61d |
---|---|
Ticket: | 1ff0660e6e5f59639e50df751d4aaabb749f5583
Tcl_DriverInputProc is not called (again) |
User & Date: | dgp 2014-07-30 17:25:58 |
Changes
- icomment:
There is a bug in the tcludp routine udpInput(). When a Tcl_DriverInputProc() returns the value 0, the core I/O parts of Tcl take that to mean a signal of EOF on the channel. udpInput() is returning 0 in several places when it does not intend that meaning. if (statePtr->doread == 0) { statePtr->doread = 1; /* next time we want to behave normally */ *errorCode = EAGAIN; /* pretend that we would block */ UDPTRACE("Pretend we would block\n"); return 0; } That should be "return -1" instead. if (bufSize == 0) { return 0; } That's arguably also wrong, but harmless since the Tcl I/O core will never pass in a value of bufSize==0. if (packets == NULL) { UDPTRACE("packets is NULL\n"); return 0; } That should probably be "return -1". If this is an attempt to signal that the channel is blocked, then there should also be *errorCode = EAGAIN; and finally.... if (bytesRead > -1) { return bytesRead; } That might also return 0, whenever recvfrom() returns 0. If those circumstances correspond to EOF, then all is fine. Otherwise the above should be preceded by something like if (bytesRead == 0 && ThisIsNotEof()) { *errorCode = EAGAIN; return -1; } With those fixes, I think tclUdp will work again with current dev sources of Tcl and will also continue to work with all the deployed releases of Tcl. Is there an active upstream to send these changes to?
- login: "dgp"
- mimetype: "text/plain"