Re: Notes when applying IO channel patch

[Owen Taylor <otaylor redhat com>]

Ron Steinke <rsteinke w-link net> writes:

> > From: Owen Taylor <otaylor redhat com>
> >
> > Ron Steinke <rsteinke w-link net> writes:
> 
> > > > * Calling g_io_channel_seek() in g_io_channel_write_chars()
> > > >   is rather odd.
> > > 
> > > This has to do with mixing read/write on a buffered channel.
> > > 
> > > If a write is followed by a read, the contents of the write buffer
> > > need to be flushed to disk before the read, so that the read starts
> > > after the last character written to the buffer.
> > > 
> > > Similarly, if a read is followed by a write, the read buffer
> > > needs to be "flushed" so that the write starts immediately
> > > after the last character read from the buffer. This
> > > is done by calling seek() to reposition the file pointer
> > > at the head of the buffer. This is also why mixing
> > > reading and writing doesn't work for encoded channels
> > > (which can't use SEEK_CUR).
> >
> > But there is no reason to actually make a seek() syscall, right?
> > You are just reusing the code in g_io_channel_seek_position()? 
> > That's what seemed a bit hackish to me. (But probably perfectly
> > OK.)
> 
> No, it's necessary. Calling g_io_channel_seek_position()
> with G_SEEK_CUR and an offset of zero actually
> calls the system call seek() with an offset
> of -(channel->read_buf->len). This backs up the file
> pointer by the length of the read buffer, so it now
> points to the location in the file corresponding to the
> head of the read buffer.

Doh, yes. :-)

Regards,
                                        Owen