chan_voter: List traversal in multiple threads without locking

[mkmer]

The client list is traversed here:

app_rpt/channels/chan_voter.c

Lines 4617 to 4622 in e98b2cc

	for (client1 = clients; client1; client1 = client1->next) {
	if (client1->curmaster) {
	lastmaster = client1;
	client1->curmaster = 0;
	}
	}

and here:

app_rpt/channels/chan_voter.c

Lines 930 to 944 in 1814fa7

	for (client = clients; client; client = client->next) {
	if (client->nodenum != p->nodenum) {
	continue;
	}
	if (!client->drain40ms) {
	client->drainindex_40ms = client->drainindex;
	client->rxseqno_40ms = client->rxseqno;
	}
	client->drainindex += FRAME_SIZE;
	if (client->drainindex >= client->buflen) {
	client->drainindex -= client->buflen;
	}
	client->drain40ms = !client->drain40ms;
	}
	}

and here:

app_rpt/channels/chan_voter.c

Lines 1637 to 1643 in 1814fa7

	for (client = clients; client; client = client->next) {
	if (client->nodenum != p->nodenum) {
	continue;
	}
	if (!client->heardfrom) {
	continue;
	}

and:

app_rpt/channels/chan_voter.c

Lines 1811 to 1815 in 1814fa7

	for (client = clients; client; client = client->next) {
	if (client->nodenum != p->nodenum) {
	continue;
	}
	if (p->priconn && !client->mix) {

(and more)

It appears there are up to 3 threads looking at the client list (and client data) that have some contention, potentially looking through a list that is revised when a client disconnects and reconnects.

Similar issue with the privates?

app_rpt/channels/chan_voter.c

Line 4710 in e98b2cc

for (p = pvts; p; p = p->next) {

[ve7fet]

There is definitely lots of code cleanup needed in this channel driver.

I'm still trying to figure out a reliable way to detect when a client has disconnected, (and what to reset when they do).

Looking forward to being able to make this a little more cleaner and more reliable.

[mkmer]

Wanted to put it on your radar as you dig. I noticed this as a possibility for the behavior our RTCMs are exhibiting on reconnect... One of many possibilities :)

[ve7fet]

Adding an update that the client connect/disconnect code has been refactored for better client handling.

Working now on fixing the (apparently) broken "redundant proxy server" connect/disconnect code that doesn't seem to work as originally intended.

Once that is complete, a PR will be linked against this issue to review for appropriate locking.