socket.recvfrom() & sendto()

[Donn Cave]

Quoth grante at visi.com (Grant Edwards):
| In article <z94K6.49410$2U.21218265 at news2.rdc2.tx.home.com>, Ron Johnson wrote:
|> Greg Ewing wrote:
|>| Ron Johnson wrote:
|>|> 
|>|> how can the client accept input from the
|>|> user at the same time that it is "stalled" at a select() ?
|>| 
|>| By including the file descriptor from which you're
|>| reading user input in the select().
|>
|> That works on unices, but not on Win32, according to the python.org
|> documentation, and my wife wants to play the game on her PC...
|>
|> Or am I missing something else???
|
| No, you're not.  Win32 has numerous blatant design problems,
| and that's one of them.

I'm a big fan of the device abstraction as supported by UNIX, that
makes select() work the same on a tty or socket or pipe.  Always
nice, but sadly rare, to see that come along with Berkeley sockets
on a non-UNIX platform.

But in the present case, is this really a serious complaint?  I don't
know Windows all that well, so it's not clear to me, are we talking
about some tty-like device that serves a DOS window, or would you
want to select() on keyboard+mouse and get any event that belongs
to your graphic application?  Marginal benefit, or unreasonable
expectation?

When I have run into this on BeOS, the way out seems to be a
special socket that's local to the application.  Some UI thread
can dispatch events through the socket, where the network thread
can pick up on them.  I don't know how useful that would be outside
of BeOS, but I think the moral of the story is that no single
dispatching mechanism is likely to have access to all possible
classes of events, but you can hybridize them by giving each
dispatcher a way to talk to the others.

	Donn Cave, donn at oz.net