Trying to build with the android standalone compiler, and these 2 things
were causing errors. I don't know what an equivalent to basename would
be, because I don't really know what it does.
For consistency with Java NetworkTable; also makes these data types easier
to use (although they are less efficient as they require a memory allocation
and data copy).
During JVM shutdown, some JNI calls may not return, so it's not possible to
reliably perform a join() during static variable destruction (which occurs
as the JVM unloads the JNI module).
Also, due to static variable destruction, it's not safe to use any members
of a static class instance from a separate thread of execution.
SafeThread is a templated thread class and a related owner class that's
designed for safe operation and shutdown of threads in the presence of
callbacks that may not return. It also passes ownership of variables from
the static instance to the thread, so the thread can safely operate until
it exits (the last operation of the thread being to destroy its instance).
Notifiers, RpcServer, and Logger now use SafeThread to ensure race-free
destruction in both C++ and Java.
All Java callback threads are now marked as Java daemon threads so they
don't keep the JVM running after main() terminates.
All Java callback threads are now named so their purpose is more easily
identified in a debugger.
Add SetRpcServerOnStart and SetRpcServerOnExit (similar to Listener).
The previous use of a timeout resulting in thread detach instead of thread
join resulted in a race condition on Mac between destruction and thread
closeout. This commit removes the detach functionality and uses dup2() to
on Linux/Mac and connecting to itself on Windows to try to ensure accept()
exits.
Each call to AttachCurrentThread results in a new Java thread object being
created. This is inefficient and also causes debugging issues with Eclipse
due to constant creation and removal of threads. Now AttachCurrentThread is
only called once for (all) listeners and once for logging (if used).
Previously this would always return false due to how explicit bool is
evaluated in a return context.
Also add a test for this function.
Reported by: jcreigh
This is safe because of the way writes are performed: for each transmission,
all outgoing messages are concatenated in memory and only a single write()
syscall is made.
These are good to have for backwards compatibility, but discouraged for new
development (default-taking functions should be used instead). The reason
is that the exceptions must be explicitly handled and may initially work but
then fail at an inopportune moment.
Mark the similar Java functions as deprecated as well for the same reason.
Update all the docs for consistency.
Mark overridden functions as such in both C++ and Java.
Make IsPersistent and GetFlags const in C++.
The Value::MakeStringArray methods were not setting the size of the
arr_string. This was causing the NT_Value struct called from the C
entry listener callback to not have the array size, which would then
cause the GetValueStringArray method to fail the malloc.
Under certain situations (notably JNI shutdown), it's possible to get
deadlock when using thread join(). To avoid this, implement a timeout.
Normally we try to simply join the thread, but if it times out, we
detach the thread instead.
This enables listeners to be notified of not only value updates, but also flag
changes and deletions by using a bitmask to specify what notifications are
desired. The old API (which only provided a new/not new) flag is still
supported. This also subsumes the feature to listen to local changes (that's
one of the bitmask options).
Before the server has assigned the id, the client doesn't generate flags
update messages. This behavior is correct, but the client must then send
the appropriate flags update message when the id is finally assigned by
the server.
The default behavior is to only notify remote changes, but for some
applications (e.g. GUI's) it's advantageous to know about local
changes as well.
This is (slightly) optimized in that local changes only result in
additional resources being consumed if (any) local listeners have been
created.
This matches the implementation provided by Java NetworkTable, with the
exception that the subtable is not provided (because it's not a value).
The listener still can get access to the subtable by calling
source->getSubTable(key).
