Unix Domain Sockets are inaddressable remotely, and more efficient,
as well as allowing future SCM_CREDENTIALS / SCM_RIGHTS.
Change-Id: Ia2472260f75feb43e9022cdfa0fe005ccd489454
Don't stop the polling thread and attempt cleanup
when the thread is no longer alive; just avoid
logging warnings and other noise.
Demote a couple warning logs to info since
they are neither critical nor actionable.
Change-Id: Ibe8e8491723f1beeaea03a6e935d606b01e275f0
Matches the behaviour of real sockets in a real Online server better.
Seems to get rid of the occasional hang problem.
I had already some time ago suspected that such a change would fix
that problem, but unfortunately my first attempt missed one crucial
detail, so it didn't, and I spent days looking for other ways to fix
the problem instead, in vain.
Probably I should add some sanity limit on the number of buffered
messages, though... But if such a sanity limit then would be hit, most
likely much else is totally broken already anyway.
Change-Id: Ice43057814ee5abd85b2935ffaa91765845a515a
In 1c7f94045a that introduced
DelaySocket, its getPollEvents() could indeed return -1, but that was
removed later.
Change-Id: Ie3a7e01b7b9a7517d97f6ed3cc6d96bdb3313969
Reviewed-on: https://gerrit.libreoffice.org/61990
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Add plumbing to send messages from the Online code to the JavaScript
code, and vice versa. Similar to what is done for iOS.
Sadly, it crashes. Multi-thread issues. Not surprisingly, it crashes
when I call webkit_web_view_run_javascript() in another thread than
the one where the GTK+ and other Webkit calls were done. I need to
come up with some clever way to do everything from the same thread.
(On iOS, I use dispatch_async(dispatch_get_main_queue(),...) to
schedule a block (i.e., a lambda expression) to be run in the main
thread.)
The wakeup() call in SocketPoll::stop() doesn't always (or ever?)
actually cause the wakeup code to be invoked and callbacks called
right after, and we don't want to risk the leftover callbacks being
invoked when the same SocketPoll object is started again. (This did
actually happen.)
In a normal Online, this is not a problem, as SocketPolls aren't
reused. One document per kit process, a separate kit process for each
document. Not so in a mobile app, there we have just one process that
handles document after document as the user closes one, opens another
(or the same anew), etc.
Previously SocketPoll expected to be
running its own thread for polling.
This is unnecessary when we have a
spare thread (e.g. main) that can
(and should, for efficiency) be used
for polling rather than starting
dedicated thread.
Not starting the SocketPoll's thread
and calling SocketPoll::poll() directly
worked, the warning logs on each activity
notwithstanding.
The warnings aren't just noisy, they are
a performance drain as well, and signal
that something is wrong. The new code
now makes the API cleaner and avoids
unnecessary warning logs, while being
faster.
Change-Id: Ibf9a223c59dae6522a5fc2e5d84a8ef191b577b1
The async-signal-safe functions to get thread-id
and thread-name, which cache the results, are
faster, cleaner, and signal-safe. No reason why
we shouldn't always use them.
Especially since it appears the logic was
inverted in Log::prefix, such that the signal
un-safe calls were made during signal-handling,
and the safe ones were called otherwise!
Instead of passing the signal-safe flag to
Log::prefix, we pass the buffer size, for
improved security.
Furthermore, reduce header dependencies
and reduce clutter.
Change-Id: I697689b2f0a290b6d8cce4babc3ac1e576141da6
I am trying to get a SocketPoll object to be "restartable".
Also make the lambda expression in joinThread multiple lines, so that
one can set a breakpoint in it.
Makes things simpler and easier to follow, I hope. I had hoped it
would also make the occasional hang I see when loading the document go
away, but nope. Possibly it isn't caused by FakeSocket after all, even
if FakeSocket is the obvious first suspect.
