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