Re^3: Client/Server sockets with TK on Win32

Even with your (very sensible) modification, under windows, the listener's readable event handler is never called. Even though the connection from client to server is established. And even if the listener socket is set nonblocking.

My conclusion is that Tk fileevents simply do not work on windows.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re^3: Client/Server sockets with TK on Win32

Replies are listed 'Best First'.
Re^4: Client/Server sockets with TK on Win32 by zentara (Cardinal) on Apr 17, 2012 at 10:45 UTC
The OP might want to look at Another Win32 Tk fileevent work around : using ioctl() properly I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply]
Re^5: Client/Server sockets with TK on Win32 by BrowserUk (Patriarch) on Apr 17, 2012 at 11:12 UTC
I don't know why you think that would make any difference. The description of "how to use ioctl properly" is moot. You'll notice that he doesn't say that using the oft-described method of setting non-blocking doesn't work, only that it works "for the wrong reasons". That's okay. *Just so long as it works!* His "proper way" is no such thing. It is at best a different way of working around the fact that the implementation of ioctl is broken. There is no way that Perl programmer's should be messing around with pointers. pack 'p' (or is it pack 'P') is even more badly documented than ioctl and far, far too easy to get wrong and cause crashes. The proper way would be to fix ioctl. Those examples do not use Tk fileevents. Tk fileevents don't work on Windows. Ergo: The OPs approach will not work on Windows. The limitation is in the Windows Tk implementation. Not Perl, nor Windows. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]
Re^6: Client/Server sockets with TK on Win32 by zentara (Cardinal) on Apr 17, 2012 at 13:39 UTC
The limitation is in the Windows Tk implementation. Not Perl, nor Windows. Yes, it seems like deja vu all over again. :-) I remember the fileevent problem on MSWindows being discussed so much in the past, but recently, some monks have reported that fileevent now works on MSWindows. I guess it's a matter of which Windows version and patches one might have? What else can account for the wide discrepancy in fileevent's functionality? But if the OP wants to switch to Glib and Gtk2, he can be assured that the Glib IO watcher does work on MSWindows. He should see Glib based forking server with root messaging where the Gtk2 client is a look-alikeclone of the Tk version. He would then have a working cross-platform program. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply]
Re^6: Client/Server sockets with TK on Win32 by Anonymous Monk on Apr 18, 2012 at 05:28 UTC
FWIW, Re^2: Client/Server sockets with TK on Win32 doesn't work for me either under Tk or Tcl::pTk, but Tcl-pTk-0.85/t/fileevent.t does work (its a pipe open to perl program), but it i switch `use Tcl::pTk;` with `use Tk;` in Tcl-pTk-0.85/t/fileevent.t then it doesn't work So problem with Tk.pm yes Maybe socket problem with Tcl::pTk, or maybe with Tcl	[reply] [d/l] [select]