On Friday 08 April 2005 11:22 pm, Jason Gillis wrote:I've worked up a possible fix for the "Mutex destroy failure" problem on the master backend that comes up when a slave backend disconnects at the wrong time.
I think there's a couple subtle threading issues with this patch due to the fact that signals are going to be sent/handled in the same thread that's sending them. The destroyConnect signal will then possibly be sent from one of the worker pool threads, but the endConnect function handler is written assuming that it will only be called from the main qt event loop.
I figured it wasn't perfect, if only for that ASSERT problem alone. I suppose it's one of those things that looked good on paper, but didn't work out so well in practice.
When I was debugging, it seemed like the thread that was doing the reading was the same one that was also handling the endConnect signal from ReadStringList() when the socket closed, so I wasn't really sure what the best way to handle the problem was. There didn't seem to be any way to get the socket read to end while still in the endConnection() function.
Do you think a better solution would be to have a separate thread that's just in charge of reaping closed connections occassionally? That is, mark them for destruction and have this new thread look at the list occassionally to see what needs to be removed properly?
Jason
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
