Subject: Re: [linux-audio-dev] the alternate API for LAAGA: its problems
From: Francois Dechelle (Francois.Dechelle_AT_ircam.fr)
Date: Thu Jul 05 2001 - 17:36:01 EEST
Paul Davis wrote:
>
> The difficulty with that approach is that there are other reasons why
> we might have been interrupted. In particular, I have found that
> looping on EINTR can be very dangerous in threaded programs because
> they seem to be able to avoid exiting ...
>
> However, I suppose with a little work:
>
> int the_fd_changed;
>
> signal (SIGWHATEVER, fd_changed); // more likely sigaction
> to allow proper semantic control
>
> void fd_changed (int sig)
> {
> the_fd_changed = TRUE;
> }
>
> the_fd_changed = FALSE;
> if (select(n,&rfds,&wfds,&efds,0) < 0) {
> if (errno == EINTR && the_fd_changed)
> laaga_fd = laaga_get_process_start_fd();
> else
> exit(1);
> }
>
> This still looks a bit ugly, but it would work OK. There is another
> problem too: you have to keep track of the thread ID of the thread
> that will be doing select/poll (so you call pthread_kill() it). The
> docs for the function would have to make clear that it must be called
> only from the thread that will use it in this way.
>
> --p
Do you think it is mandatory to provide the file descriptor to the application
code ? i.e. is the function laaga_get_process_start_fd() really unavoidable ?
It is OK if the application wants to build a select() call with several file
descriptors, some file descriptors coming from other places than LAAGA.
But if the select is going to be called with only one file descriptor set,
which will be the one provided by laaga, then why not encapsulating the
select() in a LAAGA function ?
(fd =
This archive was generated by hypermail 2b28 : Thu Jul 05 2001 - 17:37:53 EEST