At Mon, 07 Oct 2002 19:46:44 +0200,
Abramo Bagnara wrote:
but the current behavior is incorrect from the interpretation of
POSIX. so this must be a bug.
if we have to change it, then i would choose the new one, because
it's more intuitive without exception.
As pointed by
At Fri, 04 Oct 2002 20:04:00 +0200,
Abramo Bagnara wrote:
Takashi Iwai wrote:
At Fri, 4 Oct 2002 10:14:09 +0200,
Anders Torger wrote:
Uhhh... I guess ignoring me works just as well :-)
not ignored but pending :)
Abramo, do you still have objection to change the default
Takashi Iwai wrote:
it CAN happen if you have multi-threads.
the problem is that we have no option to block the poll.
If you have multi-thread you have other alternative to do that.
OTOH application can't detect *why* poll is blocking with the change you
advocate.
That apart I'm sure that
Abramo Bagnara wrote:
Takashi Iwai wrote:
it CAN happen if you have multi-threads.
the problem is that we have no option to block the poll.
If you have multi-thread you have other alternative to do that.
OTOH application can't detect *why* poll is blocking with the change you
advocate.
as
Anders Torger wrote:
On Monday 07 October 2002 14.07, you wrote:
Takashi Iwai wrote:
it CAN happen if you have multi-threads.
the problem is that we have no option to block the poll.
If you have multi-thread you have other alternative to do that.
OTOH application can't detect
Paul Davis wrote:
I'm not speaking about programming bugs. Suppose the PCM is stopped by
another thread: you're screwed.
why are you screwed? you're waiting (presumably) for data/space to be
ready in the PCM device. there isn't any (or more precisely, you're
waiting for changes in the
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
---BeginMessage---
[ abramo: please forward to [EMAIL PROTECTED] thanks. ]
I'm strongly convinced that to
Paul Davis wrote:
[ abramo: please forward to [EMAIL PROTECTED] thanks. ]
I'm strongly convinced that to have poll waiting for something that
cannot happens is a big mistake (also as an optional behaviour).
there are several, perhaps even lots, of other device drivers in the
linux
On Wednesday 18 September 2002 21.57, Anders Torger wrote:
On Tuesday 17 September 2002 16.40, Clemens Ladisch wrote:
I feel that one can interpret both ways, so it is a quite open
choice. Either way, one can state POSIX behaviour. Then the
question becomes: what is the most usable
At Fri, 4 Oct 2002 10:14:09 +0200,
Anders Torger wrote:
Uhhh... I guess ignoring me works just as well :-)
not ignored but pending :)
Abramo, do you still have objection to change the default behavior?
i don't mind that even the new behavior is optional e.g. via
snd_pcm_sw_params. but i
Tim Goetze wrote:
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 definitely there's nothing to wait from sound
card.
Anders Torger wrote:
On Monday 16 September 2002 21.31, you 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 definitely there's nothing to
On Tuesday 17 September 2002 10.12, you wrote:
Please use technical argumentations: pseudo statistical and
subjective ones does not worth a lot.
Actually, that is exactly the type of argumentation you use yourself.
It is not anything wrong with that either. It is always subjective why
a
Abramo Bagnara wrote:
let's imagine:
* a single-threaded app. if the coder omits starting the stream before
poll, he'll quickly find out that nothing is played/recorded, and that
poll will hit the timeout, and consequently revise his code logic.
It would be definitely not easy for the
At Tue, 17 Sep 2002 11:05:44 +0200 (METDST),
Clemens Ladisch wrote:
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
At Tue, 17 Sep 2002 13:55:10 +0200 (CEST),
tomasz motylewski wrote:
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
IMHO the current behaviour is the proper behaviour as implemented by other
file descriptors, and as mandated by POSIX.
http://www.opengroup.org/onlinepubs/007904975/functions/write.html
says regarding pipes, FIFOs and sockets:
| The write() function shall fail if:
the discussion here is about
On Tuesday 17 September 2002 14.52, you wrote:
At Tue, 17 Sep 2002 13:55:10 +0200 (CEST),
tomasz motylewski wrote:
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
Please understand that it's very hard to satisfy everybody and I'm not
sure it's a worthy goal.
Who do we know that would be unsatisfied by the proposed change in the
behaviour of poll(2) on an ALSA device?
--p
---
Sponsored by: AMD - Your
On Tuesday 17 September 2002 15.03, you wrote:
IMHO the current behaviour is the proper behaviour as implemented by
other file descriptors, and as mandated by POSIX.
http://www.opengroup.org/onlinepubs/007904975/functions/write.html
says regarding pipes, FIFOs and sockets:
| The write()
On Thu, 12 Sep 2002, Takashi Iwai wrote:
At Thu, 12 Sep 2002 13:48:56 +0200,
Anders Torger wrote:
(...snipped the analogy of pipes...)
Well, I have the same opinion, I'd just like to give another example
(actually the same all over again, but I want to make it obvious). For
a
Takashi Iwai wrote:
if it's on the blocking mode, the driver should block if it's possible
to do write in future _by any chance_.
if it's not on the blocking mode, the driver should return -EAGAIN.
and, the behavior of poll() depends on the behavior of write().
if it blocks, then poll blocks,
Anders Torger wrote:
On Wednesday 11 September 2002 23.52, you wrote:
Anders Torger wrote:
[...]
The problem here is that the output buffer is full, the pcm is not
RUNNING, but the file descriptor gets triggered anyway. When can
that happen?
we had a hauntingly similar discussion about
Takashi Iwai wrote:
btw, the attached patch is a quick and untested hack to change the
behavior as you wish :)
please give a try.
i've already worked around it, but i think we save future coders
some work if we get this done right.
anyways, your patch doesn't break jackd (ice) and my
On Wed, 11 Sep 2002, Anders Torger wrote:
I use a RME9652 hammerfall with two periods (the hardware is that way).
I watch a file descriptor associated to the output with select(), when
it gets ready for writing, I write data to the pcm with
snd_pcm_writen(). In the beginning, the state
Anders Torger wrote:
On Wednesday 11 September 2002 20.48, you wrote:
On Wed, 11 Sep 2002, Anders Torger wrote:
I use a RME9652 hammerfall with two periods (the hardware is that
way).
I watch a file descriptor associated to the output with select(),
when it gets ready for writing, I
26 matches
Mail list logo
