[haiku-commits] Re: haiku: hrev50183 - src/servers/media src/kits/media headers/private/media headers/os/media

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 4 Apr 2016 16:07:25 +0200

Am 04/04/2016 um 15:33 schrieb Dario Casalinuovo:

> So, can I ask you again to explain what do you try to achieve with
> this semaphore, and why it would be necessary.
I'm trying to achieve a global synchronization for media rosters. What I
would like to do is allow certain threads to wait until the
media_services are ready. I'm planning to add at some point a way to
restore the BMediaNode status where it left, so when the ControlLoop is
in a certain state it could just pause until the media_server returns
up. The BMediaRoster role is to wait for it to happen and then write to
the control ports to make the node restore it's objects such as the
buffers and timesource. Using a semaphore allow a simple design that can
be used in various situations not limited to notifications itself.

But a semaphore always has an owner. If that goes away, the semaphore goes away, too. Where is the difference between:

A) Client asks server for semaphore
-> Server replies with semaphore
Client waits on semaphore
-> Server releases semaphore when ready
Client connects node
-> Server does what's needed to make that happen

and:

B) Client starts node
- Server waits until it's ready, and then does what needs to happen

I don't see the benefit of the additional complexity of the protocol.

Bye,
   Axel.


Other related posts: