On Tue, 06 Nov 2012 08:07:42 GMT
"Sönke Ludwig" sludwig@rejectedsoftware.com wrote:

On Mon, 5 Nov 2012 23:06:20 -0500, Nick Sabalausky wrote:

Does vibe.d's TCP stuff have anything along the lines of the
BSD-style sockets select()?

Not in that exact form, but using rawYield() until
InputStream.dataAvailableForRead() (on any of the connections)
becomes true would be similar for waiting for the first data that
comes available.

But usually it would be simpler/more robust to just have a separate
task for each connection that performs normal, blocking operations. A
vibe.core.signal.Signal can then be used to wake up a central
coordinator task that handles each event appropriately.

Yea, that's what I ended up deciding to do anyway. I'm doing a
multiplayer game server, so I was thinking of having one task per "game
session", so the game session has easy access to each player's TCP
socket. But as I thought about it more, I realized: 1. That may
complicate the handling of connecting/disconnecting (esp. since each
game session is locked to the same players, similar to chess), and 2.
That design might not scale as easily to a load-balanced cluster of game
servers. (Then again, maybe I was wrong...Damn, I gotta
think about it some more...)

I did want to ask about the signal stuff though, to get a better feel
for it:

What sorts of expected use-cases is that for?

Does it make sense to have different signals to the same task
indicating different things?

If you signal twice in a row (either the same signal twice, or once with
one signal and then once with a different signal), does the target task
get woken up twice, or just once and then, if it needs to, it queries
the change in the count value to see how many times it was signaled?

What if the count value wraps around?

Is it like Posix OS "signals" (which I'm not super familiar with) or a
more general (more light-weight? or are those already light-weight?)
concept of signaling?

(I gather that the signaling is all done with libevent, but
unfortunately I'm not entirely familiar with that either.)