Manfred Spraul <[EMAIL PROTECTED]> writes:
> Btw, do you know if the file pointer must be atomically updated?
> Eg you have a file with fixed size, unordered records. You could open
> the file, start 10 worker threads, and all of them just executed:
>
> for(;;){
> read(fd,&data,sizeof(data));
> if(EOF)
> break;
> process_data(&data);
> }
>
> Do you know if we have to ensure that no record is returned twice, no
> record is missed? I just checked the POSIX standard, but I found no clear
> answer. Neither 2.2.13 nor 2.3.29 enforce that.
From http://www.opengroup.org/
ssize_t read(int fildes, void *buf, size_t nbyte);
The read() function attempts to read nbyte bytes from the file
associated with the open file descriptor, fildes, into the buffer
pointed to by buf.
[snip ... ]
Files that do not support seeking, for example, terminals, always read
from the current position. The value of a file offset associated with
such a file is undefined.
Even if it was the case (that read() and write() happened
atomically), the above code wouldn't work because it is allowed to
return <= nbytes (for instance if you get a signal without
SA_RESTART).
For cases like the above you need to use pread() to get reliable
information, so it's a waste of CPU IMO to do any locking at all.
--
James Antill -- [EMAIL PROTECTED]
I am always an optimist, but frankly there is no hope.
-Hosni Mubarek
