ahead of processing data arrived on the same socket, with EnqueueKill
that adds to same queue from which data's taken. So if device dies
immediately after sending data there won't be a race between closing
the cref (if this is the last open socket) and handling the data. I'm
still dying with assert fails when running 100 games at once, but much
less frequently
(e.g. socket closes) can also be queued; track what sockets are
currently being handled so no two threads are ever processing events
on same socket. This makes running 'NGAMES=50
./scripts/discon_ok2.sh' crash very infrequently rather than every
time, but the race condition in crefmgr remains. Queuing socket
closes should help.
threads can't share the same db connection. So synchronize all
queries. Multiple threads *can* access the db concurrently as long as
each has its own connection, so I could add connections to the tpool
threads. But this will probably be performant enough for the first
10K simultaneous users. :-)
ALLCOND until it's time to kill the cref. When one device connects
and leaves the cref is recycled, so when a new device joins and is
assigned the same game and a new cref is initialized the number of
players already registered must be set from the db entry; do that.
HostRec. This fixes failure to reconnect so that now a complete game
is possible (gtk version) without the two devices every being
connected at the same time.
consistent: nJoined in DB tracks players "ever seen and issued
connName" rather than "currently connected". Next step: debug game
between two devices never connected at same time.
simplify things by using a db to survive a crash/reboot. So far (with
next checkin) manages to update a db. Next need to do queries instead
of searches through in-memory data.
game works to completion with both signing up as guests (no -s) with
one local and one remote player (identical commandlines.) Not yet
tested: if any signs up as a host, reconnecting rather than
connecting, etc. This is just a snapshot.
device id, to relay, one for each stored game that's communicating via
the relay. Relay parses out each relayID. Next relay can use these
to look up whether messages are available and reply with that, and
device can put up a notification.
