Re: [AD] Mini-synchronization API proposal for 4.1.x

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On March 26, 2002 08:02 pm, you wrote:
> On 2002-03-25, Eric Botcazou <ebotcazou@xxxxxxxxxx> wrote:
> > > if mutexes do nothing then wouldn't that be a bit odd? how would that
> > > be handled? (can't wait in the handler...)
> >
> > That's indeed annoying. This mutex API was primarily intended to make the
> > callback functions atomic when pthread timers are used
>
> [snip]
>
> > Solution (a) would lead to clearly state this dissymmetry in the docs,
> > but that would sound a bit technical.
>
> To me, this is unacceptable, and very misleading.  IMHO, I now think
> that mutexes were the wrong choice.
>
>
> Alternative proposal (idea taken from Thomas' message):
>
> Allow temporary disabling of _user_ callbacks, and during the disabled
> period, delay pending callbacks by putting them in a queue.  IIRC,
> this is similar to what Michael did with the SIGALRM driver.
>
> I think this is feasible on DOS (given a finite queue so it could be
> locked in memory), and should be fine on Unix+SIGALRM.
>
> Threaded ports should be fine, too.  One possibility is for a separate
> thread to wait on a condition variable, signaled when it should start
> running callbacks from the queue.  If another thread needs to run a
> callback, it either adds it to the queue or calls it directly.
> Probably it would be better to _always_ queue.

hmmm. I suppose thats (so far) the best _all around_ sollution so far. *But* 
;) it sound like it just may have a fairly high overhead...

p.s. Always complaining... and never helping... :( I really got to get around 
to finishing that ALSA 0.9.0beta12 midi driver patch... (I've adjusted the 
config script (.in) to check for the actual version of alsa, and return it so 
the different alsa modules can check to see if the right version is 
installed. the version is returned as 4 items, major, minor, subminor, and 
extra, so a certian module can contain code that even only just workes with a 
certian beta, if required.)

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx
http://strangesoft.net