From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: MIDI+USB - one way? Date: Mon, 05 Aug 2002 14:24:10 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <3D4E3AB0.563AB976@ladisch.de> <3D4E5613.96D45644@ladisch.de> Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <3D4E5613.96D45644@ladisch.de> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Clemens Ladisch Cc: Jaroslav Kysela , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Mon, 05 Aug 2002 12:40:19 +0200, Clemens Ladisch wrote: > > To quote one of the standards (I think IEEE 1003.1 is POSIX) > : > | When attempting to read a file (other than a pipe or FIFO) that > | supports non-blocking reads and has no data currently available: > | > | If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN]. > | > | If O_NONBLOCK is clear, read() shall block the calling thread until > | some data becomes available. > | > | The use of the O_NONBLOCK flag has no effect if there is some data > | available. > | [...] > | Upon successful completion, where nbyte is greater than 0, read() > | (...) shall return the number of bytes read. This number shall never > | be greater than nbyte. The value returned may be less than nbyte if > | (...) the file is a (...) special file and has fewer than nbyte bytes > | immediately available for reading. For example, a read() from a file > | associated with a terminal may return one typed line of data. ok, it's clearly mentioned here. then we should fix this behavior. > > > (and i believe that no applications suffer by this change.) > > Yes, because applications expect the OSS behaviour. > > I didn't really look at the OSS PCM read() implementation, but the > sequencer read() already implements the correct POSIX behaviour. i don't think that the oss pcm interface ever suffices the definition of posix above. but we cannot change it since most of applications assume that the read aligned in a block size. in the case of alsa, this low-level behavior can be changed, because the difference can be absorbed inside the alsa-lib. but i see no good reason to change this now. Takashi ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf