On 02/04/11 12:46, ольга крыжановская wrote:
On Fri, Feb 4, 2011 at 6:29 PM, David Korn<d...@research.att.com> wrote:
Subject: ksh93 problem on opensolaris
--------
I have been tracking down a problem that only seems to be reproducable
on Solaris.
The problem boils down to the behavior of
llseek(fd, (off_t)0, SEEK_CUR)
On must systems, this just returns the current stream offset.
On solaris, it also seems adds 0 to the current offset and then calls
llseek(fd , current_offset, SEEK_SET)
Not literally, but yes, this is the way Solaris behaves, down in the kernel.
The cause is that all of the [l]lseek() calls end up going through
common code that ends up setting the file offset to the newly-
computed offset. The code needs to make a special case of this
and not set the file offset if it is not actually being asked to change.
Now, if another process is using this stream, this presents a
race condition since it might move the stream pointer between
the time that the offset is found and the time the SEEK_SET
is called.
This is what is happening the the case that I am tracking down.
Is there anyway that solaris can change this behavior for offset 0?
Sure. I'll file a bug report and fix it in Solaris 11.
Do you want a patch to be made for Solaris 10?
Roger Faulkner
Solaris is the *only* operating system which acts this way.
Linux, FreeBSD, NetBSD, Apple OS X, HP UX and Irix all have write sys
calls which are atomic to lseek/SEEK_CUR.
In my opinion it can not be true that Solaris is the only operating
system which violates common sense in this usage case. The FreeBSD and
OpenBSD developers I consulted on IRC even consider this a serious
bug.
Olga
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
