Re: Notes when applying IO channel patch

[Ron Steinke <rsteinke w-link net>]

> 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.

Ron