Hi, On Sun, Mar 06, 2016 at 08:34:38AM -0500, Selva Nair wrote: > On Sun, Mar 6, 2016 at 4:31 AM, Gert Doering <g...@greenie.muc.de> wrote: > > > I'm not sure if I understand in which scenarios data is fed to the > > nascent openvpn.exe on stdin - buf if done at all, we should better do > > it right :-) - I do wonder, though, if WriteFile() could block here, > > leading to a dead worker thread... all other pipe operations seem to > > go through AsyncPipeOp() - but that is orthogonal to this fix) > > > This is used for writing the management password to stdin. The GUI sends an > "ascii" password, but a client could potentially use some char set that > needs 3 or 4 bytes per char.
Ah! Tanks for the explanation, this is showing my lack of familiarity
with using the management interface in a programmatic fashion... (I use
it on the server side and manually telnet to it, having the password in
a file)
> And you are right, the write should not block. We don't see any deadlock
> even when openvpn errros out early, because of buffering, I suppose.. But
> bettter to make this non-blocking.
For "short" writes, it shouldn't block, no. On a unix pipe, you'd get
blocking if the buffers fill up and the reader is just sitting there and
not fetching the data - if the reader *dies*, the server would get an
error back (since nobody could ever read it).
Probably not very important, just wondering.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
signature.asc
Description: PGP signature
