Re: Outstanding GIOChannel issues

[Ron Steinke <rsteinke w-link net>]

From: Owen Taylor <otaylor redhat com>
>
> Ron Steinke <rsteinke w-link net> writes:
>
> > The implementation of the new GIOChannel API for 2.0 is mostly complete, but
> > there are a few outstanding issues I'd like some comments on:
> > 
> >   * win32 implmentation:
> >
> > ...
> > 
> >     The problem in this area that worries me is that we haven't made up our
> >     minds how to handle O_BINARY (bug 57695). Ideas? Opinions? Anyone?
>
> Let's:
>
>  * Always specify O_BINARY on platforms where it matters

The win32 people will need to include this in g_io_channel_new_file (),
then. Win32 people, any opinions? Does anyone care?

> Despite getc(), I think this should be g_io_channel_read_unichar()
>
> If we add that, should we add add g_io_channel_write_unichar()?
> though that's an even more trivial function:
>  
>  gchar buf[6];
>  gint len = g_unichar_to_utf8 (buf, 6);
>  return g_io_channel_write_chars (buf, len, NULL, &error);
>
> I think you should go ahead and add read/write_unichar().
> As you say, read_unichar() is very painful to implement in
> terms of the current API, 

Calling g_io_channel_write_chars () will only work for
non-NULL encodings, where any partial write will break
at UTF-8 character boundaries. Given the additional
facts that:

1) By sticking to non-NULL encodings, the implementation of
   g_io_channel_read_unichar () doesn't need to worry about
   validation.

2) Character-at-a-time doesn't make much sense on
   binary channels, unless you define "character" to
   mean "byte", in which case you can just use
   g_io_channel_[read,write]_chars () with count = 1.

I've implemented these for non-NULL channels only. Code
is in CVS.

>
> Partial writes on non-blocking sockets are fine. What I've been
> saying we should avoid is partial writes on blocking sockets.
>
> Yes, we should still use a partial_chars_buffer() for partial chars in
> the EGAIN case. Otherwise, e.g., the above write_unichar() function
> doesn't work in the non-blocking case. Having a guarantee that an
> whole number of characters appears to be written is quite useful.

Error handling in g_io_channel_write_chars () is now fixed along
these lines. Code in CVS.

> >   * minor issues
> > 
> >     * public/private parts of GIOChannel:
> > 
> >       I've marked the close_on_unref flag public, since it's
> >       safe to have users twiddle that one. Everything else
> >       is marked private. The only exception that may be necessary
> >       to this are the is_readable and is_writeable flags,
> >       which the people at GNet may need to twiddle in
> >       their wrapper for the unix shutdown() function,
> >       among other places.
>
> Just because a struct member member is marked public, doesn't mean
> that it can be twiddled. The rule is that generally public members are
> readonly. The reason for this is that even when reading a field
> directly is "safe" there is usually accompanying state that needs
> to be affected when changing the field.
>
> What I would say is:
>
>  - If there are fields that need to be modified by people other
>    than io-channel implementations, there should be public
>    accessors.
>
>  - If we allow external implemenetations of IO Channels
>    than we should add accessors for any fields they need
>    to change.
>
>  - If we don't allow external implemetnations of IO channels,
>    then we should move the IOChannel struct into a private 
>    header. 

There are really only three fields we need to worry about:

close_on_unref
is_readable
is_writeable

The close_on_unref flag should be freely settable by the user,
so I need to write g_io_channel_[set,get]_close_on_unref ().

The is_readable and is_writeable flags need to be updated
in certain cases, e.g. partial shutdown of a socket. The most
sensible way to do this is probably to have a call to
g_io_channel_get_flags () update these, since the backend
already calls fcntl (). Normal users could ignore this,
and anyone who needs have them updated could call
get_flags on those (rare) occasions when it was necessary.

Other than these issues, there's no reason not to make the
GIOChannel structure private.

Ron Steinke