That's good news pion.
I'm also looking at one more "big" chance to fix the lockup problem once and for all. I can't prove everything yet, but it appears that winsock async message notification used for port/pasv connections requires the use of a helper thread(s). I can show from memory dumps that a thread never created by ioFTPD itself is at fault in the loader lock bug. It abandons the loader lock somehow and I can't find anything else creating threads except this socket helper thread. However, and this is the interesting part, overlapped notification via the winsock extensions AcceptEx, ConnectEx doesn't seem to create that extra thread. I had no reason to suspect this might be true until pion was able to confirm that he could login more than 10 times into a locked up server that wouldn't transfer files. That meant that one of the two notification methods used by the server was still working!
Given the above pieces of information I'm going to try to yank the whole winsock event notification stuff and only use overlapped notification via the winsock extensions... The funny thing is, I just re-wrote the way winsock event notification works to prove it wasn't doing anything wrong! There is one other possibility here that I can't figure out how to prove but might play a factor. It turns out that thread creation is "dangerous" because each new thread requires all dlls that have an initialization function receive thread creation/deletion messages and the loader lock is used to protect this event. Perhaps it's some dll unrelated to winsock that is having issues and is causing that thread to terminate for some reason but doing so in a way that the loader lock is still held... I'll have to explore that as well, but obviously one answer would be to try and never created those winsock helper threads in the first place!
For the moment I'm just happy that servers which were having this problem can run without people having to keep a close eye on them to restart after lockups.
|