Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion IO opinions -- lines vs records vs streams

Newsgroups: perl.perl6.internals
Path: controlnews3.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <ti...@dansat.data-plan.com>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 67084 invoked from network); 10 May 2004 09:34:59 -0000
Received: from x1.develooper.com (63.251.223.170)
  by onion.develooper.com with SMTP; 10 May 2004 09:34:59 -0000
Received: (qmail 22441 invoked by uid 225); 10 May 2004 09:34:58 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 22433 invoked by alias); 10 May 2004 09:34:58 -0000
X-Spam-Status: No, hits=0.0 required=7.0
	tests=
X-Spam-Check-By: la.mx.develooper.com
Received: from mail03.svc.cra.dublin.eircom.net (HELO mail03.svc.cra.dublin.eircom.net) (159.134.118.19)
  by la.mx.develooper.com (qpsmtpd/0.27.1) with SMTP; Mon, 10 May 2004 02:34:57 -0700
Received: (qmail 78048 messnum 150124 invoked from network[213.94.228.233/unknown]); 10 May 2004 09:34:54 -0000
Received: from unknown (HELO dansat.data-plan.com) (213.94.228.233)
  by mail03.svc.cra.dublin.eircom.net (qp 78048) with SMTP; 10 May 2004 09:34:54 -0000
Received: from dansat.data-plan.com (localhost [127.0.0.1])
	by dansat.data-plan.com (8.12.9/8.12.9) with ESMTP id i4A9Z4ko032605;
	Mon, 10 May 2004 10:35:04 +0100 (BST)
	(envelope-from ti...@dansat.data-plan.com)
Received: (from timbo@localhost)
	by dansat.data-plan.com (8.12.9/8.12.9/Submit) id i4A9Z0JO032601;
	Mon, 10 May 2004 10:35:00 +0100 (BST)
Date: Mon, 10 May 2004 10:34:59 +0100
To: Jeff Clites <jcli...@mac.com>
Cc: Dan Sugalski <d...@sidhe.org>, perl6-intern...@perl.org
Subject: Re: IO opinions -- lines vs records vs streams
Message-ID: <20040510093459.GA32443@dansat.data-plan.com>
References: <a06100506bcc2c0709ea2@[172.24.18.98]> <CC03FE16-A14B-11D8-80C7-000393A6B9DA@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CC03FE16-A14B-11D8-80C7-000393A6B9DA@mac.com>
User-Agent: Mutt/1.4i
X-Spam-Rating: onion.develooper.com 1.6.2 0/1000/N
Approved: n...@nntp.perl.org
From: Tim.Bu...@pobox.com (Tim Bunce)

On Sat, May 08, 2004 at 04:59:52PM -0700, Jeff Clites wrote:
> On May 8, 2004, at 10:30 AM, Dan Sugalski wrote:
> 
> >Do we want to make a distinction between record reads and just plain 
> >"read me X (bytes|codepoints|graphemes)" requests on filehandles and, 
> >if so, do we think it's worth distinguishing between fake records 
> >(line-oriented things) and real records (where there's a fixed record 
> >size or absolute record marker)?
> 
> I'd say that there's no need to distinguish. C's stdlib tries to be 
> record-oriented, and I've never found it to be useful. Trying to be 
> record-oriented (for what people today want from records) at the IO 
> level seems awkward--and it's easy to write (at the user level) a "give 
> me the next token" interface on top of a byte-source or a 
> character-source, and there's not a lot of benefit to modeling this as 
> IO.
> 
> >(Note that, regardless of anything else, we do need to separate out 
> >stream IO and record IO, both for layer filtering reasons and for pure 
> >practicality as there still are some pure-record filehandles (UDP 
> >sockets and such) even on a Unix system)
> 
> On Unix, record-oriented IO is specific to sockets only (not 
> filehandles in general). Not sure what you mean by "layer filtering".

If I write to a filehandle for a file opened in append mode I want
(to be able to make) that write still be atomic when it gets to the
operating system (ie not broken up into multiple writes, or merged
with previous data).

Tim.