- Rather than depending just on mount_server's launch, instead use
a condition that waits for the volumes mounted event. Had missed
the existence of this one previously.
- Adjust launch configuration such that media_server requires mount_server.
Otherwise, if the user has specified sound files for any events that are
on non-boot disks, these won't be found/loaded properly during the boot
process.
* Killing the thread leaks resources, and it will terminate cleanly and
safely when the destructor exits anyway.
* Fixes #12293. Thanks to ttcoder, jackburton and bonefish for investigating!
* Does not fix #12286. Going to bissect now...
UiUtils:
- Fix incorrect check to see if we had hit the bounds of the current memory
block that would cause us to overflow the block's data buffer if incorrect
length values were passed in.
* The code is just reversed to be better organized.
* Since the first event will be handled after a port write, at thread
spawn we just wait with infinite timeout for new messages.
* Remove goto which then become a continue.
* This permitted to remove the double waitUntil assignment which
was in different braces.
* lateness var become tempLateness, so it become more obvious than
before that it's a cached value and we are doing this to avoid
double calculus.
This reverts commit c2e9a9227ecadca3a4fdc7e7f7569fb9c7dc1391. I
misunderstood what Diver meant -- apparently whe he said "revert",
he meant the whole changeset, not this specific commit. So the culprit
is probably BTextView then.
This reverts commit fd3e3e7bfb6e31cced1a98fc6a24c45f2feeba93.
Apparently this code wasn't duplicated, as it caused all sorts of
problems in applications (e.g. Debugger was blank).
Fixes #12269.
* The first problem was the O(n^2) complexity of the algorithm, it's
now linear and try to act in a circular way by dispatching
events and reading the port in a balanced way. This exclude
a certain degree of possible deadlocks.
* Add detection and escape when the system try to kill the
thread. This solve some blocking issues on exit et similia
that i had with libjackcompat.
* The algorithm choose soon which event to focus on.
* Lateness is calculated just before the event is dispatched
as it is the more appropriate place, otherwise we would be
calculating something imprecise/guessed.
* Remove timed_event_queue::queued_time. It's more precise to
just use the RealTime() before to Dispatch the event.
* It should solve the BSoundPlayer lateness problems.
* With those improvements the media_kit is not going to lock
completely under stress conditions, instead it try to work
in a best effort shape.
* There's still room for improvements, for example i'm considering some
strategies in lateness situations such as update scheduling latency,
try to decrease waiting time and detect when we are too early on
the other hand to recover when the load go down.
* Thanks to Julian Harnath for sharing his WIP patch which helped
with some controls such as avoiding negative lateness.
* Comments are welcome!
This reverts commit 5934b30b95a239eee4a088a9b9cb425eef13f22d.
* It got the way of an heisenbug and it seems this change
fixed the problems, but after 2 days the media_server returned
to block. Sorry about that! Will investigate further.
TCPEndpoint::Free() uses _EnterTimeWait() to start the time-wait timer
for later cleanup. The latter did call _CancelConnectionTimers()
unconditionally however, also cancelling a retransmit timer that was
possibly still needed for the retransmission of the FIN packet. If the
FIN packet got lost, the connection would be left open on the other end.
The APICall trace entry just records the function name but this is
enough to deduce where some of the state changes come from.
Also move the TRACE macros past the MutexLockers to ensure that their
output happens at the time when the methods actually run.
The retransmit timer was only stopped when all in flight data was
acknowledged and never updated on individual acknowledgements. This
caused a lot of erroneous retransmits whenever the buffer was filled
fast enough so that the acknowledgements never caught up, i.e. whenever
uploading or streaming data.
Move setting of the initial retransmit timer inside the send loop so it
is closer to the actual time the segment is sent out and simplify the
logic a bit.
Limit the minimal retransmit timeout to 200 msecs to avoid spurious
retransmit in the face of delayed acknowledgements. This is lower than
the 1 second minimum the RFCs suggest. Other stacks use various other
sub-second timeouts, the 200 msecs follows what Linux does.
Also add the exponential back off of the retransmit timeout when
retransmits are triggered. This is bounded by a 60 seconds maximum
according to RFC6298.
The WaitList implementation had a race condition between checking for
the condition and acquiering the semaphore. If a thread was rescheduled
at that point, the signal could be missed due to the use of
release_sem_etc() with the B_RELEASE_ALL flag while the thread was not
yet waiting for the semaphore. The transfer would subsequently stall.
