[haiku-development] Re: media_kit: handling events in a quantum of time
- From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 19 Apr 2016 13:28:25 +0200
Hi,
On Mon, Apr 18, 2016 at 9:53 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
Am 16.04.2016 um 22:10 schrieb Dario Casalinuovo:
[...]
What are A and latency in this inequation?
A is the real time at which the event is handled.
[...]
Just to chime in: I have a hard time understanding you, too, Dario.
Could you please spend some extra time actually answering to Ingo's
questions with more than a one liner, and not miss out half the questions
on the way?
Really, I don't think makes sense to do kilometric discussions. At least
while I try to always put discussions but there's a risk of becoming bored
of it.
To be more clear I tried to describe the situation where an event B is
scheduled to be executed while the event A is already processing.
Calling read_port_etc() is the cost of a syscall, BTW. You just need to
add the time for this to the estimated latency.
I've been simply thinking that it would be easier to expect a certain
number of messages from the port, handle them (in order?), and execute N
events. If we were going to do that we could then define a quantum, that is
calculated based on the number of inputs, the downstream latency (min/max)
and their correlaton. At this point we could also define that quantum as a
sort of "cycle" and warranty that an event will be executed in the next
cycle.
Of course, I think it's something that should be put in a BMediaClient
rather than a BMediaEventLooper.
For the scheduling latency, we already have a function to estimate it
(which could certainly be improved a lot, if you're interested in doing
that).
Ok I might look into it.
It seems to me you are trying to wrestle against several problems at once,
which doesn't really make much sense.
I think instead that this part of the media_kit should work well, and I
mean always well..
First, the timing and latency computation (if there are any issues) should
be fixed.
Nothing prevents you to add an event conflicting with another.
There simply cannot be any reasons for deadlocks in normal operation.
Yes that's why at this point the new ControlLoop() I introduced in
BMediaEventLooper is the best we can do.
It's not just a problem of optimization, the BMediaClient with it's
Binding() system will suffer of that in a terrible way. So the best
solution would be to implement a custom ControlLoop() or, maybe better,
just fork BMediaEventLooper and continue from that.
--
Best Regards,
Dario
Other related posts:
