Instead of marking the handle as not running by setting the handler's
value in the map to false, we now remove simply the key if there is no
handler running. This also means we no longer need to use a weak hash
map for this.
Also reduce the size of the synchronized blocks, mainly by scheduling
the handler outside of the synchronized(threadActiveMap) block.
Make some code better readable and add some more comments. Also do
start a new handler thread if the task threw.
Those, relatively new, listeners guarantee that the individual
listeners are not invoked in concurrently while preserving the
order. Exactly what MultiUserChat previously did with AsyncButOrdered,
which is now no longer needed and hence can be removed.
Fix a bug in the EqualsBuilder usage in UserTuneElement. Properly
synchronize listeners using CopyOnWriteSet. Make methods and fields
static where sensible and possible. Make
disableUserTuneNotifications() public (why was it private?). And a few
other minor fixes.
This commit will enable user to communicate
information about music to which user is listening.
This feature is less of a requirement and more like fun to me.
An attempt at solving SMACK-257.
Incase you see any chances of improvement,
please let me know :)
The assert on line 659 was causing my build to fail. Two issues caused
gitCommit to be empty.
1. The cmd 'git describe --always --tags --dirty=+' was not given
enough time to complete and had not exited which meant no text in
proc.text
2. The two git commands on lines 653 and 658 were run from the
CWD of my Eclipse IDE, not the $projectDir which caused git to return
an error 128.
To solve the two issues I added a waitForOrKill method call to
proc (like the srCmd had) and I set the execute to run in $projectDir
which I think was the intent/assumption in the original code.
Also add waitFor on git describe command.
If we do not peek at the scheduled actions in the reactors
synchronized block, then there is a kind of lost-update problem. While
Ractor.schedule() will call wakeup() on the selector, a thread could
have already determined the value of selectWait, while being blocked
at the start of the synchronized reactor section. Once it is able to
enter the section, it will use an outdated selectWait value.
This leads to scheduled actions not being executed on time.
Thanks to Eng ChongMeng for reporting this and suggesting the fix.
