UnitPrefork got what I assume is one of those PING frames that
ChildProcess::isAlive() sends before the actual reply when it sent the
"unit-memdump" message, and did not like it. Uncommenting the line
that outputs the "memory stats" message it expects showed:
Got memory stats 'PING'
Followed by:
Assertion `tokens.count() == 2' failed.
Fix by factoring out the handling of PING frames, PONG frames, and the
pseudo-PONG frames that we send ourselves in reply to PING frames into
a new function IoUtil::receiveFrame(). Use that in a couple of
places. (Probably should use in many more places.)
Getting past this then leads to later cppunit tests again being run,
and their failures then again showing up...
Note that we currently have unit tests that incorrectly (IMHO) require
some frames sent by the server to indeed be 'text' ones from the
WebSocket perspective. That is an unnecessary restriction.
Will be used in unit test to verify that several clients of the same
document asking for the same tile simultaneously indeed do cause just
one tile rendering to take place.
This is to distinguish the deliberate close of connection, and timeout,
connection drop, or forced close.
When the last session is closed non-deliberately, force a save so that the
edits are not lost.
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?
This is a single json that contains both load and rendering options.
Currently only the rendering ones are added to it by the client.
Also, just accept the options string for now, a later commit will have
to actually pass the rendering part to
lok::Document::initializeForRendering().
When requested, the document is exported under
/jail_path/CHILD_ID/user/thedocument/RANDOMDIR/filename
and CHILD_ID, RANDOMDIR and the filename are communicated to the client.
When the client requests
http://server:port/CHILD_ID/RANDOMDIR/filename, the exported document
is served and then RANDOMDIR is removed
Implementing this Was harder than I first expected. The basic idea is as
follows: The master process puts each message arriving from a client that
isn't "canceltiles" into a (client-specific) queue. A separate thread that
pulls messages from the queue at its own pace and handles them as
before. Incoming "canceltiles" messages are handled specially, though: The
queue is emptied of "tile" messages.
The above sounds simple but there are several details that were a bit tricky
to get right.
Remove any intersecting cached tiles. It is the parent process that handles
the tile cache, so it must look for invalidatetiles: messages, too, before
passing them on to the client. To know for which part we should remove tiles,
add an "ephemeral" curpart: message that the child process sends to the parent
process before the invalidatetils: message.
