mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-03-16 12:03:03 -05:00
b8c4d042bd
This seems to be a knock-on effect of my recent reworking of the SSH code to be based around queues and callbacks. The loop iteration function in uxsftp.c (ssh_sftp_do_select) would keep going round its select loop until something had happened on one of its file descriptors, and then return to the caller in the assumption that the resulting data might have triggered whatever condition the caller was waiting for - and if not, then the caller checks, finds nothing interesting has happened, and resumes looping with no harm done. But now, when something happens on an fd, it doesn't _synchronously_ trigger the follow-up condition PSFTP was waiting for (which, at startup time, happens to be back->sendok() starting to return TRUE). Instead, it schedules a callback, which will schedule a callback, which ... ends up setting that flag. But by that time, the loop function has already returned, the caller has found nothing interesting and resumed looping, and _now_ the interesting thing happens but it's too late because ssh_sftp_do_select will wait until the next file descriptor activity before it next returns. Solution: give run_toplevel_callbacks a return value which says whether it's actually done something, and if so, return immediately in case that was the droid the caller was looking for. As it were.