Originally posted by m2kio
Is there anybody for whom aMule does not behave like this? - please raise your hand! Do you have a dual processor Mac? (just guessing..)
aMule is working pretty well for me. However, I'm behind a firewall that I don't control, so I always have Low ID. As I understand it, aMule works pretty well for you if you accept having a Low ID. So, I don't know if my experience is actually any different than yours. Also, I have dual processors.
As a somewhat educated observer, here are my observations on the stack trace revealed by sample:
1) select() is ultimately being called in the main event loop. This should never happen unless with timeout 0 so that it is just a poll(). Maybe a bug is preventing select() from honoring a 0 timeout? Although, since the freezes aren't permanent, some timeout appears to be in effect.
2) The sockets are probably being created as non-blocking. There's a chance that due to a bug in wxMac (or maybe Mac OS X), the socket isn't behaving as non-blocking. However, this might make accept() block when it shouldn't, but wouldn't be expected to change the behavior of select().
[... Ken spends some time looking at the code ...]
Um, OK, I've found something very confusing and troubling. In CListenSocket::OnAccept, there's a call to wxSocketServer::AcceptWith with the 'wait' parameter specifically set to 'true'. Also, there's a whole thing with tracking the number of pending connections (m_nPeningConnections [sic]). Why not just call AcceptWith(..., false) until it fails? Don't bother tracking pending connections at all. Or, just call AcceptWith(..., false) once and, if there are more pending connections queued up, rely on GSocket/wxSocketServer to issue further notifications/events. Unless I misread the code, it will issue such notifications until the queue is empty.
I think what is happening is that the count of pending connections is getting out of sync with the actual queue of pending connections. So, you are attempting more AcceptWith calls than there are actually connections to accept. It is very possible for a connection request to arrive at a listening socket, trigger wxMac's internal signalling mechanism to issue the LISTENSOCKET_HANDLER event, and before the AcceptWith call is issued, the connection could be closed. Then, you will try an AcceptWith with no actual pending connection in the queue. It will block until a new, different connection actually is made, or maybe it will eventually time out.
Edited to suggest: Those of you who compile aMule for yourselves can do the following to test my theory. In aMule-2.0.0rc7/src/ListenSocket.cpp, change line 2266 from
if (AcceptWith(*newclient, true)) { to
if (AcceptWith(*newclient, false)) {(just changing 'true' to 'false').
Rebuild aMule and test it.
