- 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 c2e9a9227e. 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.
* For better performance, we allow doing drawing mode changes
(and thus, B_OP_COPY) again when inside an opaque layer which
has only other opaque layers below it in the layer stack.
As soon as the first non-opaque layer turns up in the stack, the
drawing mode will be locked to alpha composite mode, until this
layer stack is ended entirely.
This allows using B_OP_COPY in many cases as used by WebKit.
* In the long term it would be nice to get rid of the drawing-mode
lock altogether, however that would need some larger refactoring
work in Painter (i.e. remove the offsetting from renderer_region
again and instead implement an "exit-level transform" (support
for offsets is enough) in Painter which is applied after all other
transforms).
* Opaque layers (opacity = 255) don't need to use an intermediate
bitmap (and everything that comes with it) for drawing at all,
they can just directly draw onto the underlying canvas or layer.
(WebKit likes to use plenty of opaque layers)
* Invisible layers (opacity = 0) can simply be ignored.
This reverts commit fd3e3e7bfb.
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 5934b30b95.
* 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.
ThreadHandler:
- Simplify SetBreakpointAndRun() to always use the debugger interface to
continue execution, since the latter is now intelligent enough to determine
how to handle that in all cases. Adjust callers accordingly.
- B_DEBUG_MESSAGE_CONTINUE_THREAD now checks if the thread in question
is in a suspended state rather than waiting on the debug nub port, and
if so, handles resuming it automatically. This allows the continue message
to be used on the main thread of a team that was freshly created under
debug control without the API user having to be cognizant of the distinction.
