Roger A. Faulkner wrote:
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.
Thank you very much! But, I am wondering why there is no attempt to
synchronize access to file_t structure between lseek and write.
When process 1 is trying change the offset by doing lseek over fd1, if
another
process attempts a write over fd2 which shares file_t structure with
fd1, I thought
write should get blocked until lseek is complete. But, I don't see
any locking
mechanism over file_t structure. Is it something that needs to be fixed?
Or, this
behavior is intentional?
Thanks,
-Sriman
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
