1
0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 01:48:00 +00:00

udp.but: update description of handle-io system.

It's been so long since Windows Plink kept its stdio subthreads in its
own main source file that I'd forgotten it had ever done so! They've
lived in a separate module for managing Windows HANDLE-based I/O for
ages. That module has recently changed its filename, but this piece of
documentation was so out of date that the old filename wasn't in there
- it was still mentioning the filename _before_ that.
This commit is contained in:
Simon Tatham 2022-01-22 14:52:46 +00:00
parent cadd86ac49
commit e262dab642

View File

@ -278,16 +278,17 @@ should be aware that you might be re-entered if a network event
comes in and is passed on to our window procedure by the
\cw{MessageBox()} message loop.
Also, the front ends (in particular Windows Plink) can use multiple
threads if they like. However, Windows Plink keeps \e{very} tight
control of its auxiliary threads, and uses them pretty much
exclusively as a form of \cw{select()}. Pretty much all the code
outside \cw{windows/winplink.c} is \e{only} ever called from the one
primary thread; the others just loop round blocking on file handles
and send messages to the main thread when some real work needs
doing. This is not considered a portability hazard because that bit
of \cw{windows/winplink.c} will need rewriting on other platforms in
any case.
Also, the front ends can use multiple threads if they like. For
example, the Windows front-end code spawns subthreads to deal with
bidirectional blocking I/O on non-network streams such as Windows
pipes. However, it keeps tight control of its auxiliary threads, and
uses them only for that one purpose, as a form of \cw{select()}.
Pretty much all the code outside \cw{windows/handle-io.c} is \e{only}
ever called from the one primary thread; the others just loop round
blocking on file handles, and signal the main thread (via Windows
event objects) when some real work needs doing. This is not considered
a portability hazard because that code is already Windows-specific and
needs rewriting on other platforms.
One important consequence of this: PuTTY has only one thread in
which to do everything. That \q{everything} may include managing