Re: GIOChannel error handling

[Johannes Stezenbach <js convergence de>]

Owen Taylor wrote:
> 
> Michael Natterer <mitch gimp org> writes:
> 
> > Johannes Stezenbach <js convergence de> writes:
> >
> > > The GIOError type is IMHO unsufficient for proper error
> > > handling, in some cases one needs access to the real errno.
> > >
> > > (E.g. reading from a device driver which can report buffer
> > > under/overruns.)
> 
> Could you be more specific here about your requirements?

I use GIOChannels for async reads from a device driver that
gives me MPEG2 section data (i.e. auxilliary information, not
audio/video data). The driver signals buffer overflows using a
non-standard errno (which is not defined in errno.h), which
requires me to discard partial data and retry the read.


> I'm not sure it makes any sense to require g_io_channel_read()
> on a Unix fd to act exactly like read() on the fd - what
> would be the point?

I think if I use g_io_channel_unix_new(), it is valid to
assume that g_io_channel_read()/write() follow unix semantics,
and I would like to use them for consistency instead of
reverting to a mix of GIOChannel functions and OS specific
syscalls. Like, fread() sets errno the same way as read() does.

Plus, maybe I could make use of the new buffering and encoding
conersion features of GIOChannel.

I think that g_io_channel_unix_get_errno() would add to
the flexibility of GIOChannels, and would not significantly
decrease portalility and abstraction. If you want to write
fully protable programs, don't use g_io_channel_unix_get_errno().
But then don't use g_io_channel_unix_new(), too.


> > I'm however biassed whether this should be g_io_channel_unix_get_errno()
> > or g_io_channel_get_errno(). Tim??
> 
> g_ui_channel_unix_get_errno(), if at all.

?


Regards,
Johannes