On Wed, 2005-12-07 at 09:30 +0100, Stéphane Letz wrote:
> Le 7 déc. 05 à 02:00, Lee Revell a écrit :
>
> > On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote:
> >> On Wed, 2 Nov 2005 11:05:34 +0100
> >> Stéphane Letz <[EMAIL PROTECTED]> wrote:
> >>
> >>> In Jackdmp we have tested 2 system fo
On Wed, 7 Dec 2005 09:30:28 +0100
Stéphane Letz <[EMAIL PROTECTED]> wrote:
> jackd (of jackdmp in "synch" mode) where the server waits for all
> clients to finish in a given cycle require the used synchronization
> primitive to have a "wait with time-out" operation. Fifo can do that
> (us
Le 7 déc. 05 à 02:00, Lee Revell a écrit :
On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote:
On Wed, 2 Nov 2005 11:05:34 +0100
Stéphane Letz <[EMAIL PROTECTED]> wrote:
In Jackdmp we have tested 2 system for inter-process
synchronization:
fifo (the way it was done in regular jackd) a
On Wed, 2005-11-02 at 11:48 +0100, Florian Schmidt wrote:
> On Wed, 2 Nov 2005 11:05:34 +0100
> Stéphane Letz <[EMAIL PROTECTED]> wrote:
>
> > In Jackdmp we have tested 2 system for inter-process synchronization:
> > fifo (the way it was done in regular jackd) and POSIX named semaphore
> > (wh
On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote:
> Btw: i just discovered that pthread mutexes and condvars can have a
> "process shared" flag which makes it possiblo to synchronize threads
> across processes as it seems. Could be useful for jack, no?
>
> pthread_condvar_setpshared()
> pt
Le 2 nov. 05 à 14:05, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 01:57:47PM +0100, St?phane Letz wrote:
So if there are N clients, each of them needs N file descriptors
open
all the time. System wide the complexity grows as N^2. Not really a
good way to tackle an O(N) problem IMHO.
On Wed, Nov 02, 2005 at 01:57:47PM +0100, St?phane Letz wrote:
> >So if there are N clients, each of them needs N file descriptors open
> >all the time. System wide the complexity grows as N^2. Not really a
> >good way to tackle an O(N) problem IMHO.
>
> Yes but in the jackdmp data flow kind of
Le 2 nov. 05 à 13:43, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 12:38:49PM +0100, St?phane Letz wrote:
Yes, clients use open *once* when the new client opens. This is done
in a non RT thread (what we call the "notification" thread that also
handle all non RT events like callback...)
On Wed, Nov 02, 2005 at 12:38:49PM +0100, St?phane Letz wrote:
> Yes, clients use open *once* when the new client opens. This is done
> in a non RT thread (what we call the "notification" thread that also
> handle all non RT events like callback...)
>
> >This means that changing the graph ord
Le 2 nov. 05 à 12:11, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 11:56:59AM +0100, St?phane Letz wrote:
I must be missing something essential here. Access to named things
that have to be opened is normally by a file descriptor, and file
descriptors are bound a process. How then can y
Le 2 nov. 05 à 11:48, Florian Schmidt a écrit :
On Wed, 2 Nov 2005 11:05:34 +0100
Stéphane Letz <[EMAIL PROTECTED]> wrote:
In Jackdmp we have tested 2 system for inter-process synchronization:
fifo (the way it was done in regular jackd) and POSIX named semaphore
(which are built on top of fut
On Wed, Nov 02, 2005 at 11:56:59AM +0100, St?phane Letz wrote:
> >I must be missing something essential here. Access to named things
> >that have to be opened is normally by a file descriptor, and file
> >descriptors are bound a process. How then can you give *all* clients
> >access to the named p
Le 2 nov. 05 à 11:29, Alfons Adriaensen a écrit :
On Wed, Nov 02, 2005 at 11:05:34AM +0100, St?phane Letz wrote:
Le 31 oct. 05 à 02:18, fons adriaensen a écrit :
A big advantage of using futexes in shared memory would be
that they don't have to be recreated each time the callback
order chan
On Wed, 2 Nov 2005 11:05:34 +0100
Stéphane Letz <[EMAIL PROTECTED]> wrote:
> In Jackdmp we have tested 2 system for inter-process synchronization:
> fifo (the way it was done in regular jackd) and POSIX named semaphore
> (which are built on top of futex on recent system version)
>
> In both c
On Wed, Nov 02, 2005 at 11:05:34AM +0100, St?phane Letz wrote:
>
> Le 31 oct. 05 ? 02:18, fons adriaensen a ?crit :
>
> >A big advantage of using futexes in shared memory would be
> >that they don't have to be recreated each time the callback
> >order changes - unlike the pipes, they are not bound
Le 31 oct. 05 à 02:18, fons adriaensen a écrit :
On Mon, Oct 31, 2005 at 01:44:45AM +0100, Florian Schmidt wrote:
Btw: i just discovered that pthread mutexes and condvars can have a
"process shared" flag which makes it possiblo to synchronize threads
across processes as it seems. Could be us
On Mon, 31 Oct 2005 10:57:46 -0500
Lee Revell <[EMAIL PROTECTED]> wrote:
> > Btw: i just discovered that pthread mutexes and condvars can have a
> > "process shared" flag which makes it possiblo to synchronize threads
> > across processes as it seems. Could be useful for jack, no?
> >
> > pthread
On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote:
> Btw: i just discovered that pthread mutexes and condvars can have a
> "process shared" flag which makes it possiblo to synchronize threads
> across processes as it seems. Could be useful for jack, no?
> pthread_condvar_setpshared()
> pthre
On Mon, 2005-10-31 at 01:44 +0100, Florian Schmidt wrote:
> On Sun, 30 Oct 2005 14:14:19 +0100
> fons adriaensen <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote:
> >
> > > Oh i thought i read somewhere that when pthread_cond_wait it is not
> > > gu
fons adriaensen <[EMAIL PROTECTED]> writes:
> On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote:
>
>> Oh i thought i read somewhere that when pthread_cond_wait it is not
>> guaranteed that anyone actually signalled. Will do some more reading.
>
> It can return on unix signals, so you
On Mon, Oct 31, 2005 at 01:44:45AM +0100, Florian Schmidt wrote:
> Btw: i just discovered that pthread mutexes and condvars can have a
> "process shared" flag which makes it possiblo to synchronize threads
> across processes as it seems. Could be useful for jack, no?
>
> pthread_condvar_setpshare
On Sun, 30 Oct 2005 14:14:19 +0100
fons adriaensen <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote:
>
> > Oh i thought i read somewhere that when pthread_cond_wait it is not
> > guaranteed that anyone actually signalled. Will do some more reading.
>
>
On Sun, Oct 30, 2005 at 01:53:48PM +0100, Florian Schmidt wrote:
> Oh i thought i read somewhere that when pthread_cond_wait it is not
> guaranteed that anyone actually signalled. Will do some more reading.
It can return on unix signals, so you have to test for EINTR.
I don't think it will wake u
On Sunday 30 October 2005 11:11, Florian Schmidt wrote:
>
> Also the basic problem of signalling (in this case the disk thread that
> there is work to do) still persists even with lockless ringbuffers. The
> other thinkable approach would be to make the diskthread wakeup
> regularly and check wheth
On Sun, 30 Oct 2005 13:36:41 +0100
fons adriaensen <[EMAIL PROTECTED]> wrote:
> This can still be so if the access to the shared data structure is
> regulated by the same mutex that protects the condition variable,
> provided that the operation on the shared data is very simple and fast.
True..
On Sun, Oct 30, 2005 at 12:11:18PM +0100, Florian Schmidt wrote:
> Btw: i think when using a single mutex only for the condition variable
> (as opposed to the tutorial client which uses the same mutex for the
> signalling _and_ for synchronizing access to its data structure), the
> likeliness of c
On Sun, 30 Oct 2005 14:03:39 +1100
Dave Robillard <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-30-10 at 00:42 +0200, Richard Spindler wrote:
> > I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses
> > mutex+condition, is it okay to do this? Are there better ways?
>
> That's a wonder
2005/10/30, Richard Spindler <[EMAIL PROTECTED]>:
> related question, what happens if I use the lockfree ringbuffer, and
> the non-realtime-thread tries to access it while it's full, how do I
> know when to try again?
Replying to myself:
I just read the capture_client.c, it uses pthread_mutex_try
2005/10/30, Lars Luthman <[EMAIL PROTECTED]>:
> It depends on how detailed information you want in the non-RT thread. If
> you just want to say "something happened!" you can use a counter of a
> datatype that you know is read and written atomically (int usually
> works) and increase it every time s
On Sun, 2005-30-10 at 00:42 +0200, Richard Spindler wrote:
> I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses
> mutex+condition, is it okay to do this? Are there better ways?
That's a wonderful tutorial... on how NOT to write a Jack client.
(There's no lock free data structures
On Sun, Oct 30, 2005 at 12:42:47AM +0200, Richard Spindler wrote:
> 1. what is the preferred way of feeding data from disk to the callback?
Use a separate thread to read ahead. Trigger it in the same way as
you would for a thread that takes data from the callback.
> 2. What is the preferred w
On Sun, 2005-10-30 at 00:42 +0200, Richard Spindler wrote:
> I have two questions concerning the jack callback,
>
> 1. what is the preferred way of feeding data from disk to the callback?
>
> Is there a general design pattern agreed upon? Best Practices?
The most common way is to use some varian
Hi,
I have two questions concerning the jack callback,
1. what is the preferred way of feeding data from disk to the callback?
Is there a general design pattern agreed upon? Best Practices?
2. What is the preferred way to notify the non-realtime thread that
something happened in the jack-callba
33 matches
Mail list logo
