5 May
2005
5 May
'05
8:56 a.m.
Hello,
Is there a simple (i.e. simpler than getting the pollfd and using them)
to force snd_seq_event_input() in blocking mode to return, so the the
calling thread can close the handle and cleanup ?
Neither snd_seq_close() nor snd_seq_nonblock() seem to have any effect.
--
FA
6 May
6 May
5:36 a.m.
Fons Adriaensen wrote:
Is there a simple (i.e. simpler than getting the
pollfd and using them)
to force snd_seq_event_input() in blocking mode to return, so the the
calling thread can close the handle and cleanup ?
You could try to send this thread a signal, but I don't know how well
signals and threads work together.
Otherwise, if you want to wait for an event other than "sequencer
event received", you must use poll.
HTH
Clemens
10:05 a.m.
On Fri, May 06, 2005 at 09:36:23AM +0200, Clemens Ladisch wrote:
I see. Still I find this strange. Shouldn't a call that waits on fd
return with an error code when that fd is closed ? If it doesn't, what
is supposed to happen to the calling thread ? Could it still wake up
if the fd is re-used afterwards ?
Since snd_seq_event_input() probably uses poll() internally, why
doesn't it test for POLLERR,-HUP,-NVAL ?
--
FA
Is there a
simple (i.e. simpler than getting the pollfd and using them)
to force snd_seq_event_input() in blocking mode to return, so the the
calling thread can close the handle and cleanup ?
You could try to send this thread a signal, but I don't know how well
signals and threads work together.
Otherwise, if you want to wait for an event other than "sequencer
event received", you must use poll.
11:54 a.m.
Fons Adriaensen wrote:
Shouldn't a call that waits on fd return with an
error code when
that fd is closed ?
The ALSA library isn't thread safe.
Since snd_seq_event_input() probably uses poll()
internally, why
doesn't it test for POLLERR,-HUP,-NVAL ?
It just calls read().
Regards,
Clemens
8 May
8 May
4:22 a.m.
On Fri, 2005-05-06 at 15:54 +0200, Clemens Ladisch wrote:
Fons Adriaensen wrote:
If so, then pthread_cancel() should work just fine together with the
workaround described under BUGS in man pthread_cancel.
Shouldn't a call that waits on fd return with
an error code when
that fd is closed ?
The ALSA library isn't thread safe.
Since snd_seq_event_input() probably uses poll()
internally, why
doesn't it test for POLLERR,-HUP,-NVAL ?
It just calls read().
Regards,
Clemens
--
(
)
c[] // Jens M Andreasen
7:36 a.m.
On Sun, May 08, 2005 at 08:22:24AM +0200, Jens M Andreasen wrote:
If so, then pthread_cancel() should work just fine
together with the
workaround described under BUGS in man pthread_cancel.
Using pthread_cancel() is exactly what I want to avoid at all cost.
In my world, threads are both the thing managaed by the system +
threads library, and a C++ object. If the thread is cancelled that
can make it virtually impossible to cleanup the object in an orderly
fashion. It may for example have to wait for a message confirming that
others that depend on its existence know it's going to disappear, and
are prepared for that. Also, the pthread itself is just a private
implementation detail of the object and can not be accessed from
the outside without breaking the abstraction.
--
FA
8 a.m.
On Sun, 2005-05-08 at 11:37 +0200, Fons Adriaensen wrote:
--
(
)
c[] // Jens M Andreasen
On Sun, May 08, 2005 at 08:22:24AM +0200, Jens M
Andreasen wrote:
Can't you use:
void pthread_cleanup_push(void (*routine) (void *), void *arg);
void pthread_cleanup_pop(int execute);
?
If so, then pthread_cancel() should work just
fine together with the
workaround described under BUGS in man pthread_cancel.
Using pthread_cancel() is exactly what I want to avoid at all cost.
In my world, threads are both the thing managaed by the system +
threads library, and a C++ object. If the thread is cancelled that
can make it virtually impossible to cleanup the object in an orderly
fashion. It may for example have to wait for a message confirming that
others that depend on its existence know it's going to disappear, and
are prepared for that. Also, the pthread itself is just a private
implementation detail of the object and can not be accessed from
the outside without breaking the abstraction.
8:49 a.m.
On Sun, May 08, 2005 at 12:00:26PM +0200, Jens M Andreasen wrote:
Can't you use:
void pthread_cleanup_push(void (*routine) (void *), void *arg);
void pthread_cleanup_pop(int execute);
Does the thread still exist as a thread when routine() is called, or more
specific, is routine() called from the thread's own context ? This is not clear
from the man page - routine() could be called from a different thread than
the one that is being cancelled.
But this is besides the point. In my original problem it is not the intention
to terminate the thread - just to force the snd_seq_event_input() to return.
The thread could well close the handle, open a new one and continue normal
operation. The simplest solution is probably to send some fake event to the
midi port.
--
FA
10:09 a.m.
On Sun, 2005-05-08 at 12:50 +0200, Fons Adriaensen wrote:
--
(
)
c[] // Jens M Andreasen
On Sun, May 08, 2005 at 12:00:26PM +0200, Jens M
Andreasen wrote:
The routine() is definately called from the threads own context. A very
common variant is routine() == free() and *arg is some malloced memory
that is only known to this thread.
Can't you use:
void pthread_cleanup_push(void (*routine) (void *), void *arg);
void pthread_cleanup_pop(int execute);
Does the thread still exist as a thread when routine() is called, or more
specific, is routine() called from the thread's own context ? This is not clear
from the man page - routine() could be called from a different thread than
the one that is being cancelled.
But this is besides the point. In my original problem it is not the intention
to terminate the thread - just to force the snd_seq_event_input() to return.
The thread could well close the handle, open a new one and continue normal
operation. The simplest solution is probably to send some fake event to the
midi port.
Perhaps poll() with a shortish timeout? Wake up now and then and do some
housekeeping. Otherwise it looks like pthread_kill would or should have
been the one if not for implementation issues (although here I am
uncertain if it isn't so that the documentation of BUGS is outdated for
kernel 2.6?)
9 May
9 May
6:10 a.m.
Jens M Andreasen wrote:
On Sun, 2005-05-08 at 12:50 +0200, Fons Adriaensen
wrote:
> But this is besides the point. In my original problem it is not the intention
> to terminate the thread - just to force the snd_seq_event_input() to return.
> The thread could well close the handle, open a new one and continue normal
> operation. The simplest solution is probably to send some fake event to the
> midi port.
Yes, you can use a user-defined event for this.
Perhaps poll() with a shortish timeout? Wake up now
and then and do some
housekeeping.
It would be better to use poll with two objects: the sequencer, and
some pipe or something like that used for communication between
threads.
Regards,
Clemens
8:55 a.m.
It would be better to use poll with two objects: the
sequencer, and
some pipe or something like that used for communication between
threads.
although i use this model as a basic pattern in ardour and other
software, i think it might be worth asking fons exactly what other
approaches he can imagine? it appears he might like something along
the lines of snd_seq_poke(), which would cause the poll on the
sequencer fd to return with POLLHUP or something related in the event
set. fons?
--p
12:07 p.m.
On Mon, May 09, 2005 at 06:56:26AM -0400, Paul Davis wrote:
although i use this model as a basic pattern in ardour
and other
software, i think it might be worth asking fons exactly what other
approaches he can imagine? it appears he might like something along
the lines of snd_seq_poke(), which would cause the poll on the
sequencer fd to return with POLLHUP or something related in the event
set. fons?
The ideal solution for me would be that closing the sequencer handle
would make the snd_seq_event_input() return with an error.
This not being the case (why not - it's the only sensible thing to
do) the next approach would be sent a dummy event. I'm using the same
method in a 'server' class where a thread is blocked in accept(),
waiting for clients to connect. The only way to get out of the
accept() when you want to close the server is to make a dummy
connection. OTOH, a blocking read() or write() on a socket can
be forced to return by closing the socket in the correct way.
I try to avoid using poll() in multithreaded apps - for me it goes
agains the grain of using separate threads. Either you have just
one, and use poll to wait on a combination of conditions, or you
use a separate thread for each condition, handle as much as you
can locally and then send a messaqge to whoever is interested in
the event. The latter approach leads naturally to clean C++
objects to handle e.g. sockets.
For inter-thread communication I don't use poll() or any other
fd based systems either, as they are quite heavy.
The ITC_ctrl object in libclthreads (used in Aeolus, JAAA and
many other things) provides a thread with 16 message queues,
16 counting semaphores and a timer. A thread can wait on any
combination of these. It uses a single Posix condition variable
(with its associated mutex), is entirely zero-copy, and with NPTL,
very fast. It can also be used in non-blocking modes, e.g. for a
RT audio thread. I'll rewrite it some time to use futexes, and then,
if the ITC_ctrl object and the message objects are in shared memory,
it will even work tranparantly across process boundaries.
--
FA
12:29 p.m.
The ideal solution for me would be that closing the
sequencer handle
would make the snd_seq_event_input() return with an error.
if it doesn't then it seems to me that there is an error in alsalib or
alsa-kernel. i hadn't realized that you were actually closing it - my
understanding was that you just wanted a way to get the poll-ing
thread to return.
For inter-thread communication I don't use poll()
or any other
fd based systems either, as they are quite heavy.
until futexes came along, they were the fastest thing in town.
pthread condition variables look cheap until you get "under the hood"
to see how they are implemented. in linuxthreads, they used kill(2),
which is massively slower than using poll/select.
i agree that with the advent of futexes, poll is no longer ideal,
however ...
unix in general continues to suffer from the lack of a generalized
"block until <something> happens" call, where <something> can be a
change in the state of a file descriptor, a POSIX signal (including
SIGALRM/setitimer timers), a fixed interval of time, a semaphore, a
sysv msgqueue, or any other model of "block-waiting" event.
as a result, if you need to wait for 2 or more kinds of conditions
(e.g. file i/o readiness changes *and* a request from another thread),
then you have to pick one API and squeeze at least one of the
conditions into it (as libclthreads does). this situation is
despicable and ugly, but i suspect it will never be fixed.
--p
2:04 p.m.
On Mon, May 09, 2005 at 10:30:04AM -0400, Paul Davis wrote:
pthread condition variables look cheap until you get
"under the hood"
to see how they are implemented. in linuxthreads, they used kill(2),
which is massively slower than using poll/select.
The ITC_ctrl thing I use was originally developed under Solaris,
about 8 years ago. Solaris pthreads & friends were comparable to
what NPTL offers now, even then.
i agree that with the advent of futexes, poll is no
longer ideal,
however ...
and the Posix primitives are the winners now.
unix in general continues to suffer from the lack of a
generalized
"block until <something> happens" call, where <something> can be a
change in the state of a file descriptor, a POSIX signal (including
SIGALRM/setitimer timers), a fixed interval of time, a semaphore, a
sysv msgqueue, or any other model of "block-waiting" event.
Depends. On the best systems, everything - even poll/select - is build
on top of primitives like semaphores and condition variables. I can only
hope Linux will evoluate in that direction too.
as a result, if you need to wait for 2 or more kinds
of conditions
(e.g. file i/o readiness changes *and* a request from another thread),
then you have to pick one API and squeeze at least one of the
conditions into it (as libclthreads does). this situation is
despicable and ugly, but i suspect it will never be fixed.
Since I tend to abstract files / sockets / everything that uses fd
into C++ classes, I just give the class its own thread to wait on
the fd. That invisible (to the class user) 'helper' thread will do
most of the work, and then trigger one of the 32 inputs of the object
owner's ITC_ctrl, which is where the waiting on multiple events is
done. No poll() is ever required.
--
FA
11 May
11 May
8:22 p.m.
On Sun, 2005-05-08 at 12:50 +0200, Fons Adriaensen wrote:
On Sun, May 08, 2005 at 12:00:26PM +0200, Jens M
Andreasen wrote:
After an update to Mdk-10.1 to Mdk-10.2 (Edition 2005?) I realize that:
The man pages on pthtreads is about an implementation approximately 3
generations old. Not even documented defaults are consistent with the
current implementation anymore.
Say:
pthread_attr_init(&some_thread_attr);
.. and after reading this in man:
inheritsched:
... ...
Default value: PTHREAD_EXPLICIT_SCHED.
^^^^^^^^^^^^
.. one would easily be led to believe that threads by default starts as
the humbliest of creatures, unless you decide otherwise (and have the
power to do so.)
In order to actually inhibit PTHREAD_INHERIT_SCHED (which appears to be
the default of the day) you'll have to also do an explicit:
pthread_attr_setinheritsched
(&some_thread_attr,PTHREAD_EXPLICIT_SCHED);
.. or else your UI-thread, file-thread etc, will compete with your
RT-audio thread as peers (given you started them from some intial high
priority thread.)
Just thought I would mention it.
Can't you use:
void pthread_cleanup_push(void (*routine) (void *), void *arg);
void pthread_cleanup_pop(int execute);
Does the thread still exist as a thread when routine() is called, or more
specific, is routine() called from the thread's own context ? This is not clear
from the man page - routine() could be called from a different thread than
the one that is being cancelled.
But this is besides the point ...
...
OK! :)
--
(
)
c[] // Jens M Andreasen
7131
days inactive
7137
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
5 participants
participants (5)
-
Alfons Adriaensen -
Clemens Ladisch -
Fons Adriaensen -
Jens M Andreasen -
Paul Davis