On ons, 2004-03-31 at 11:02, Jens M Andreasen wrote:
So go for autonomous threads. Your code will be easier to read and
maintain, and therefore also more likely to be correct.
Just for the record. You probably already know this ...
I forgot to mention the pthread_cleanup_push/pop pair which
On Wed, 31 Mar 2004 12:24:31 +0200, Jens M Andreasen
[EMAIL PROTECTED] wrote:
On ons, 2004-03-31 at 11:02, Jens M Andreasen wrote:
So go for autonomous threads. Your code will be easier to read and
maintain, and therefore also more likely to be correct.
The thing is I don't have complete
Arve Knudsen [EMAIL PROTECTED] writes:
The thing is I don't have complete control over the audio thread, a
user defined callback is involved. In working on the ALSA
implementation of the PortAudio library there has been a request for
realtime scheduling of the audio thread, similar to the
On 31 Mar 2004 10:44:15 -0600, Jack O'Quin [EMAIL PROTECTED] wrote:
Arve Knudsen [EMAIL PROTECTED] writes:
The thing is I don't have complete control over the audio thread, a
user defined callback is involved. In working on the ALSA
implementation of the PortAudio library there has been a
Arve Knudsen [EMAIL PROTECTED] writes:
True .. That was one approach I considered originally while sketching
up solutions, I guess it slipped my mind in the meantime :| I was
thinking it could possibly be an expensive operation though as NPTL
sources seem to indicate, maybe best avoided if
On 31 Mar 2004 11:39:36 -0600, Jack O'Quin [EMAIL PROTECTED] wrote:
Arve Knudsen [EMAIL PROTECTED] writes:
True .. That was one approach I considered originally while sketching
up solutions, I guess it slipped my mind in the meantime :| I was
thinking it could possibly be an expensive operation
On 31 Mar 2004 11:39:36 -0600, Jack O'Quin [EMAIL PROTECTED] wrote:
It doesn't look all that expensive. The magic is done by a platform-
dependent compare-and-swap operation. On some SMP machines that can
be slow, but generally only in high-contention situations (AFAIK).
Arve Knudsen
On 31 Mar 2004 12:50:53 -0600, Jack O'Quin [EMAIL PROTECTED] wrote:
On 31 Mar 2004 11:39:36 -0600, Jack O'Quin [EMAIL PROTECTED] wrote:
It doesn't look all that expensive. The magic is done by a platform-
dependent compare-and-swap operation. On some SMP machines that can
be slow, but
Hi,
I made serveral changes for 6.64, the change are as following:
revision 6.67
date: 2004/03/31 17:56:11; author: cltien; state: Exp; lines: +3 -2
Disable the timed out debug message, nothing wrong.
revision 6.66
date: 2004/03/31 17:42:08; author: cltien;
hi all,
sorry for cross-posting ...
i'm planning to go to the lad conference at the zkm in karlsruhe and
kindly want to ask if someone coming from the south east passes
stuttgart on the way there and is able to share a ride ...
i'd appreciate any offer and i'm willing to contribute to the fuel
Arve Knudsen [EMAIL PROTECTED] writes:
What about pthread_kill with a user defined signal (SIGRTMIN = sig =
SIGRTMAX), where the handler will call pthread_exit? Then the
registered cleanup functions should be invoked as usual.
That might be better. I haven't tried doing it that way, myself.
C.L. Tien - _ [EMAIL PROTECTED] wrote:
Hi,
I made serveral changes for 6.64, the change are as following:
To what kernel do these patches apply? Certainly not current 2.6.
If you intend to raise 2.6 patches, please ensure that they are against the
latest kernel.org kernel. And
12 matches
Mail list logo
