On Thursday 10 October 2002 16.21, Jaroslav Kysela wrote:
> On Thu, 10 Oct 2002, Anders Torger wrote:
> > On Thursday 10 October 2002 04.15, James Courtier-Dutton wrote:
> > > I don't understand which applications prefer: -
> > > 1) "PREPARED: return POLLOUT until the buffer is full, then
> > > re
On Thursday 10 October 2002 04.15, James Courtier-Dutton wrote:
> I don't understand which applications prefer: -
> 1) "PREPARED: return POLLOUT until the buffer is full, then return
> POLLERR." and which would prefer (as suggested): -
> 2) "PREPARED: return POLLOUT until the buffer is full, then
Anders Torger wrote:
>On Wednesday 09 October 2002 15.28, you wrote:
>
>
>>Clemens Ladisch wrote:
>>
>>
>>>The behaviour of polling during capture is just fine:
>>>
>>>RUNNING: block until avail_min is available, then return POLLIN
>>>DRAINING: return POLLIN until buffer is empty, then retu
Anders Torger wrote:
>
> On Wednesday 09 October 2002 09.52, Clemens Ladisch wrote:
> > Abramo Bagnara wrote:
> > > Clemens Ladisch wrote:
> > > > Abramo Bagnara wrote:
> > > > > The point is that stream is in bad state wrt read/write, this
> > > > > is the reason why poll should return POLLERR.
On Wednesday 09 October 2002 15.28, you wrote:
> Clemens Ladisch wrote:
> >The behaviour of polling during capture is just fine:
> >
> >RUNNING: block until avail_min is available, then return POLLIN
> >DRAINING: return POLLIN until buffer is empty, then return POLLERR
> >(other states: POLLERR)
>
Clemens Ladisch wrote:
>The behaviour of polling during capture is just fine:
>
>RUNNING: block until avail_min is available, then return POLLIN
>DRAINING: return POLLIN until buffer is empty, then return POLLERR
>(other states: POLLERR)
>
>The current behaviour for playback is:
>
>PREPARED: retu
On Wednesday 09 October 2002 09.52, Clemens Ladisch wrote:
> Abramo Bagnara wrote:
> > Clemens Ladisch wrote:
> > > Abramo Bagnara wrote:
> > > > The point is that stream is in bad state wrt read/write, this
> > > > is the reason why poll should return POLLERR.
> > >
> > > I think the stream is _n
Clemens Ladisch wrote:
>
> Abramo Bagnara wrote:
> > > >No data may be read/written in current stream state in the case we are
> > > >discussing.
> > (...)
> >
> > The point is that stream is in bad state wrt read/write, this is the
> > reason why poll should return POLLERR.
>
> I think the stre
Abramo Bagnara wrote:
> > >No data may be read/written in current stream state in the case we are
> > >discussing.
> (...)
>
> The point is that stream is in bad state wrt read/write, this is the
> reason why poll should return POLLERR.
I think the stream is _not_ in a bad state because one buffe
Anders Torger wrote:
> On Tuesday 17 September 2002 14.52, you [Takashi] wrote:
> > At Tue, 17 Sep 2002 13:55:10 +0200 (CEST),
> > tomasz motylewski wrote:
> > > P.S. ALSA has more possible states of fd than pipes which may be
> > > just open/closed by the other side, and eventually full. This mak
On Tue, 17 Sep 2002, Takashi Iwai wrote:
>
> but are you sure that this feature is really implemented?
> on my system, write() to an FIFO which is not opened for read doesn't
> fail, for example,
> % mkfifo /tmp/foo
> % cat /dev/random > /tmp/foo
> and cat is blocked, not failed.
No
Anders Torger wrote:
> On Monday 16 September 2002 21.31, you [Abramo Bagnara] wrote:
> > I think that the best behaviour is the current and it's also the
> > simplest to describe and to understand: poll/select never blocks when
> > there is nothing to wait.
> >
> > ... and in PREPARED state defin
12 matches
Mail list logo
