The first child had tracing enabled even after
initial startup is completed. This would leak
user details when anonymization is enabled.
Change-Id: I5325e02d1a1078bff6640af85f5672b556c00aeb
Check and fail to start if anonymization is enabled
and trace-level logging is requested. Since trace
may include data packets, which is hard to anonymize and
is likely to impact performance if attempted, it is best
to prevent tracing altogether.
Also, sort the default settings for better readability.
Change-Id: Ic83f1f2fda15e2146a5d970f03617fa460d9cbc7
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
In loleaflet.html.m4, define a macro MOBILEAPP as true if either
IOSAPP or GTKAPP is true.
Set a window.ThisIsAMobileApp property in either case, and
window.ThisIsTheGtkApp in the GTKAPP case.
The checks for ThisIsTheiOSApp in the JS could in fact all be changed
to check for ThisIsAMobileApp instead, as they were all equally valid
for the gtk+ testbed app. For instance, sending WebKit messages to the
app code works the same way in JavaScript both for iOS and
webkit-gtk+. Which is not surprising, I guess, as the underlying
WebKit is the same.
The idea is that it would work sufficiently identically, so that even
people without a Mac and without an iOS device could participate in
development of the non-iOS-specific bits, like the JavaScript, or the
online MOBILEAPP-specific plumbing. Which would be great.
No, this doesn't do anything sane yet. It does compile the same online
C++ files as the iOS app, though. (Some minor tweaks were needed in a
couple of them to silence gcc warnings.)
There is a plain Makefile, but I should change to using autofoo, too.
Eventually, this will need to be built in a separate tree from a
normal online, just like when using the --enable-iosapp configure
switch. (But for now, doesn't matter.)
Change-Id: I13e4d921acb99d802d2f9da4b0df4a237ca60ad6
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.
