That is probably what was the intent. As originally written, in case
the function encountered partial writers, and had to do several
write() calls, only the number of bytes written by the last one was
returned.
Luckily the actual return value of writeFIFO() is not used
anywhere. It is just tested for being negative.
Still there is the problem that if at first one or several write()
calls succeed but don't write the whole buffer, and then a write()
fails, the caller has no way to know that the buffer has been
partially written. But that is hopefully highly theoretical and there
is no sane way to handle such a situation anyway.
The getChildStatus() and getSignalStatus() functions returned the
latter, still the returned values were compared against
Poco::Util::Application::EXIT_OK. (Sure, both Poco's
Application::EXIT_SUCCESS and stdlib.h's EXIT_OK are zero, but that
doesn't mean one should mix them up.)
Also add two comments pondering the meaning of the code.
We are not interested in the variable being assigned an incremented
value. Its value is not used any more. We are just interested in the
value of the variable plus one. Using pre-increment gives the wrong
impression.
Sure, this is nit-picking.
So don't give it any then.
Remove the --uid option and related attempts to handle running loolwsd
under sudo, to be able to debug it. Now with loolwsd not having
capabilities, it should work fine to just run it under a debugger
normally. (For the loolbroker and loolkit processes, attaching to an
already started process is the way to debug.)
One has to love arbitrary retry counts and timeouts. Loading the
password-protected.ods in a loolkit process, with correct password
provided, takes 12 seconds on my machine. I think this slowness is
because the NSS code LO uses to do crypto wants to initialize its
crypto goodness in various ways that don't work so well inside a
chroot jail. Presumably it uses some wait with timeout when attempting
to do something which doesn't succeed. For instance it tries to run
netstat -in. (In an interactive LibreOffice the doc loads fairly
instantly.) Oh well.
It does three separate things, and the first two intentionally result
in errors, and the server probably disconnects after errors. Not
sure. This is horrible, horrible.
Having a separate "disconnect" message is a disgrace. There should be
no need for it. WebSocket has a perfectly fine graceful disconnect
mechanism already (CLOSE frames). The code needs to be prepared to
receive a CLOSE frame at any time. The code also needs to be prepared
for the underlying socket being bluntly closed by the other end,
without sending any WebSocket CLOSE frame. The only sane thing is to
handle a "disconnect" message in the same way as those situations
anyway, so why is it needed?
Sort #includes and using statements. Use 'using' consistently for all
Poco:: types. (I am not 100% convinced that using 'using' like done
here in loolwsd was a good idea after all. But at least let's be
consistent now that we do use it.)
