| Ticket UUID: | 557878 | |||
| Title: | server fails with -encoding binary | |||
| Type: | Bug | Version: | obsolete: 8.4a5 | |
| Submitter: | nobody | Created on: | 2002-05-19 06:18:41 | |
| Subsystem: | 27. Channel Types | Assigned To: | andreas_kupries | |
| Priority: | 8 | Severity: | ||
| Status: | Closed | Last Modified: | 2002-05-25 02:06:07 | |
| Resolution: | Fixed | Closed By: | andreas_kupries | |
| Closed on: | 2002-05-24 19:06:07 | |||
| Description: |
The bug affects Tcl 8.3.2 - 8.4a5 When a server socket is created and "fconfigure $sock -encoding binary" is used the server fails to call the proc specified in the socket -server command. The end result is that client sockets fail to be able to connect. This problem doesn't affect Unix-like (OpenBSD 3.0) systems from the tests that I've run. I and another person were able to verify that it fails in Windows. I tested it with Windows XP. Now, I know that fconfiguring a server socket is apparently pointless as DKF put it I believe, but it is a bug nonetheless. | |||
| User Comments: |
andreas_kupries added on 2002-05-25 02:06:07:
Logged In: YES user_id=75003 Patch committed. andreas_kupries added on 2002-05-25 01:54:30: File Added - 23688: 557878.diff Logged In: YES user_id=75003 Attaching a patch. andreas_kupries added on 2002-05-25 01:26:58: Logged In: YES user_id=75003 Yep. What happens is this: When the server socket is reconfigured the system will call TcpWatchProc in tclWinSock.c to update for which events to look. Adding some tracing statements to this routine we see: $ ./bin/tclsh84s.exe % fconfigure [set a [socket -server hoo 0]] -sockname 0.0.0.0 0.0.0.0 1143 % fconfigure $a -encoding 1143 unknown encoding "1143" % fconfigure $a -encoding binary FD_READ = 001 FD_WRITE = 002 FD_CLOSE = 032 FD_ACCEPT = 008 FD_CONNECT = 016 watch = 008 select = 008 watch/new = 000 select/new = 008 watch determines which events are watched by windows for the handle, and ACCEPT is the event sent if a new connection arrives on the socket. As we can see the ACCEPT is cleared completely. This is because the server socket is neither readable nor writable. Unix systems are not affected because they check if an acceptProc is set (tclUnixChan.c, line 2354, TcpWatchProc) and avoid messing with the masks and events if that it so. We have to perform the same check for Windows. The mechanism on Mac is unclear. This means that this report has to be given to the mac maintainers to make sure that this bug is not present for that platform too. andreas_kupries added on 2002-05-25 00:35:41: Logged In: YES user_id=75003 Actually setting any encoding, even the encoding reported back by fconfigure will cause the problem. In other words, the problem is not so much in the specific encoding chosen, but the act of performing the reconfiguration of the server socket. andreas_kupries added on 2002-05-25 00:32:33: Logged In: YES user_id=75003 Confirmed for Win2K. | |||
Attachments:
- 557878.diff [download] added by andreas_kupries on 2002-05-25 01:54:30. [details]