Alternative to callback

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Alternative to callback

Fons Adriaensen
Hello all,

I've been working most of the WE on an app that would benefit
a lot from having an alternative to JACK's process callback.

Currently, JACK creates a thread for the client and also
provides that thread's function - let's call it
jack_thread_main(). The user registers a callback,
user_process_callback().

So ignoring some details (*), we have:

jack_thread_main()
{
  while(true)
  {
    waitforfifo();
    A;
    user_process_callback();
    B;
  }
}

user_process_callback()
{
  X;
}

where A,B,X are some code.


Now imagine that as an alternative to this, we let the
user provide his/her thread funcion:

user_thread_main()
{
  while(true)
  {
    X;
    jack_thread_wait();
  }
}

while JACK provides:

jack_thread_main()
{
  waitforfifo();
  A
  user_thread_main();
}

jack_thread_wait()
{
  B;
  waitforfifo();
  A;
}

with A,B,X as before.

It's not difficult to see that while this is no longer a
'callback' model, the two forms are equivalent, and nothing
essential has changed. Returning from the process callback
has been replaced by calling jack_thread_wait().

So what is gained ? The advantage of the second form is
that the user_thread_main() function isn't restricted to
be of the simple form above. It could be something like:

user_thread_main()
{
  while(true)
  {
    for(...)
    {
      ...
      for(...)
      {
        ...
        for(...)
        {
          ...
          if(...) jack_thread_wait();
          ...
        }
        ...
      }
      ...
    }
    ...
  }
}

Basically this is an algorithm that is spread over
several 'callbacks'. Of course it's possible to do
exactly the same using the standard callback method,
but then the user has to

1. save/restore all auto variables in user_thread_main,
2. simulate somehow continuing from within a nested
   control structure,

while in the second form he/she gets this for free,
along with a much more readable form of the code.

So what I try to show here amounts to the simple fact
that by forcing the user to put his/her code into a
callback, he/she is deprived of the advantages of
working within a thread, where the actions 1. and 2.
above are provided automagically by the save/restore
of the stack and program counter by the threads lib.

The app I've been working on has a structure that
is very close to the example above, so this is not
fiction at all.

(*) taking these into account doesn't change the
point I want to make, and would just complicate
the examples.

--
FA







 



















-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Alternative to callback

Stéphane Letz

Le 4 déc. 05 à 22:28, fons adriaensen a écrit :

> Hello all,
>
> I've been working most of the WE on an app that would benefit
> a lot from having an alternative to JACK's process callback.
>
> Currently, JACK creates a thread for the client and also
> provides that thread's function - let's call it
> jack_thread_main(). The user registers a callback,
> user_process_callback().
>
> So ignoring some details (*), we have:
>
> jack_thread_main()
> {
>   while(true)
>   {
>     waitforfifo();
>     A;
>     user_process_callback();
>     B;
>   }
> }
>
> user_process_callback()
> {
>   X;
> }
>
> where A,B,X are some code.
>
>
> Now imagine that as an alternative to this, we let the
> user provide his/her thread funcion:
>
> user_thread_main()
> {
>   while(true)
>   {
>     X;
>     jack_thread_wait();
>   }
> }
>
> while JACK provides:
>
> jack_thread_main()
> {
>   waitforfifo();
>   A
>   user_thread_main();
> }
>
> jack_thread_wait()
> {
>   B;
>   waitforfifo();
>   A;
> }
>
> with A,B,X as before.
>
> It's not difficult to see that while this is no longer a
> 'callback' model, the two forms are equivalent, and nothing
> essential has changed. Returning from the process callback
> has been replaced by calling jack_thread_wait().
>
> So what is gained ? The advantage of the second form is
> that the user_thread_main() function isn't restricted to
> be of the simple form above. It could be something like:
>
> user_thread_main()
> {
>   while(true)
>   {
>     for(...)
>     {
>       ...
>       for(...)
>       {
>         ...
>         for(...)
>         {
>           ...
>           if(...) jack_thread_wait();
>           ...
>         }
>         ...
>       }
>       ...
>     }
>     ...
>   }
> }
>
> Basically this is an algorithm that is spread over
> several 'callbacks'. Of course it's possible to do
> exactly the same using the standard callback method,
> but then the user has to
>
> 1. save/restore all auto variables in user_thread_main,
> 2. simulate somehow continuing from within a nested
>    control structure,
>
> while in the second form he/she gets this for free,
> along with a much more readable form of the code.
>
> So what I try to show here amounts to the simple fact
> that by forcing the user to put his/her code into a
> callback, he/she is deprived of the advantages of
> working within a thread, where the actions 1. and 2.
> above are provided automagically by the save/restore
> of the stack and program counter by the threads lib.
>
> The app I've been working on has a structure that
> is very close to the example above, so this is not
> fiction at all.
>
> (*) taking these into account doesn't change the
> point I want to make, and would just complicate
> the examples.
>
> --  
> FA

So basically you're proposing a blocking version of the process API  
along with the callback model. It seems like a good idea... I  
remember PortAudio also tries to propose both callback and blocking  
based access to the audio stream.

I guess an "API changes proposal" list for post 1.0 version should  
now be kept somewhere...

Stephane

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel