There are people who claim that they can listen while they talk and not lose a bit of information,
but in practice that's not true, and either information stream is unreliable.
It makes perfect sense that wanting to write to a socket you don't pretend to read from it, it's not
the task at hand. Does it really make sense to
- whenever a socket becomes writable, stop reading, and start writing, and at the same time
- whenever a socket becomes readable, stop writing, and start reading?
I have found my programs to be less confusing if they are driven by just one of these fileevents.
Generally, that means:
- in server code, 'readable'. When done with reading, process, start writing, and
- in client code, 'writable'. When done with writing, start reading, process.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
But the same algorithm using Event::Lib or plain select() works perfectly (tested), so what's wrong with Tk's event loop?
BTW, people are using computers for such "too difficult for people" tasks. And i don't see any problem in sending and receiving data at the same time on full duplex channel, that tcp connection claims to be.
| [reply] |
Dunno what's wrong with it... I didn't dig much into Tk internals and have not time for that currently.
But thinking again... do you attempt to bind the fileevent to the same widget? If so, that could
be the gotcha. I don't know whether it is possible to bind multiple fileevents to the same widget, but I suspect
it not being possible.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |