While the peer does not drain its receive buffer, every forwarded packet
would re-stall the reader thread for up to writeTimeout(), so a queued
Disconnect frame could wait behind the whole backlog. Remember a stalled
target (send slower than 2 s) and drop data for a short cooldown instead
of stalling; keep dispatcher writes bounded at 3 s. Control frames
(Connected/Disconnected) are unaffected.
newConnection pushed the client into clients while holding map_mutex
but started its read thread after releasing it; in that window the
client was a live member of clients with no read thread and could be
marked, closed and deleted by the drainer before start() ran. Start
the thread inside the locked section: the thread can only wait for
map_mutex after the function has released it, so this is not a
deadlock, and the 'everything in clients is started' invariant holds.
~DispatcherServer dropped clients/servers pending in rmrf_clients/
rmrf_servers without closing or deleting them (object leak of live
PIObjects). Collect them together with the main maps, then run the
same stop/close/delete sequence. The sets are disjoint with the main
maps by construction (items are removed from the main maps when
marked), so there are no duplicates.
The dataReadedServer lambda looked up the sub-client under
mutex_clients but called sendData() after the unlock; the client could
be deleted by the drainer in between (same UAF pattern that was fixed
in PICloudServer::_readed). Keep the send inside the locked section:
sendData only takes mutex_send/prog_s_mutex downstream, so the lock
hold is bounded.
cleanClients() (timer thread) called close()/stopAndWait() and
disconnectClient() (read thread) did the same while holding
map_mutex, while client read threads wait for the same lock in
registerServer/registerClient/disconnectClient — a guaranteed
deadlock (the -w watchdog aborts exactly this). disconnectClient
could also wait for its own read thread (self-wait in
waitThreadedReadFinished) and the destructor never stopped the timer
or drained the clients, leaving dangling lambda captures of this.
Restructure around a single drainer (the timer thread):
- cleanClients: under map_mutex only mark (move rmrf_* out, mark
ping-timeout/orphaned clients); after the unlock close
(stopAndWait) and delete the connections, then delete the servers
- disconnectClient: only mark under the lock, then request a
non-blocking stop() on the affected connections; the drainer waits
and deletes (no self-wait, nothing blocks while holding the lock)
- newConnection: start the read thread after releasing the lock
- ~DispatcherServer: stop watchdog/timer first, then close and delete
all clients before the servers (raw-pointer order) and eth
The watchdog is now a PIThread member so the destructor can stop it;
setMaxConnections takes map_mutex like its readers.
stop() iterated clients while addClient()/removeClient() modified it
from other threads (reallocated vector iterators, data race). Copy the
list under mutex_clients and close the copy.
last_ping (PITimeMeasurer) was reset from the read thread
(dataReadedServer/pingReceived) without any lock while cleanClients
read it via lastPing() in the timer thread. Reset and read it under
mutex_clients (lock order map_mutex -> mutex_clients, consistent with
the registerClient path).
in almost all methods removed timeouts in milliseconds, replaced to PISystemTime
PITimer rewrite, remove internal impl, now only thread implementation, API similar to PIThread
PITimer API no longer pass void*
PIPeer, PIConnection improved stability on reinit and exit
PISystemTime new methods
pisd now exit without hanging
andrey
peri4
Бычков Андрей