Re: concurrent write(2) calls write bad data to file

Article View: comp.bugs.4bsd

Article #572

#572

From: Jan Edler
Date: Mon, 09 Mar 1987 22:43

14 lines
1198 bytes

Our version of UNIX has locked the file table entry on every write
for several years now.  The only time it doesn't is when writing
to a "slow" device, like a terminal (and such devices don't usually
maintain the notion of "file position" anyway).  Nulls do not appear
in the output file when running the posted test program.

I don't see any really good reason for not handling this case correctly;
there is some overhead in getting the extra lock, but that doesn't
seem like a good enough reason to me.

Jan Edler
New York University, Ultracomputer Project
edler@nyu
cmcl2!edler

Technical Details

Message-ID: <13578@cmcl2.UUCP>

Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!cmcl2!edler

References: <692@rtech.UUCP> <14589@sun.uucp>

Show Full Headers

Complete Article Headers

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!cmcl2!edler
From: edler@cmcl2.UUCP (Jan Edler)
Newsgroups: comp.bugs.4bsd,comp.unix.wizards
Subject: Re: concurrent write(2) calls write bad data to file
Message-ID: <13578@cmcl2.UUCP>
Date: Mon, 9-Mar-87 17:43:06 EST
Article-I.D.: cmcl2.13578
Posted: Mon Mar  9 17:43:06 1987
Date-Received: Tue, 10-Mar-87 07:15:26 EST
References: <692@rtech.UUCP> <14589@sun.uucp>
Reply-To: edler@cmcl2.UUCP (Jan Edler)
Organization: New York University, Ultracomputer project
Lines: 14
Summary: It can be done correctly

Reply to Parent Message