Re: Notes when applying IO channel patch

[Owen Taylor <otaylor redhat com>]

Johannes Stezenbach <js convergence de> writes:

> Owen Taylor wrote:
> > 
> > If we remove ERANGE, EBADMSG as being STREAMS things, say that
> > we warn and don't return EBADF and EFAULT, and handle EGAIN
> > and EINTR internally, then the set is:
> 
> EAGAIN can happen on non-blocking file descriptors only, and
> there it makes no sense to handle it internally: The user
> asked for it by setting the file descriptor to non-blocking
> and needs EAGAIN for status notification.
> 
> Besides, how would you handle EAGAIN internally?
> Busy waiting until the read/write() call succeeds?

By "internally", I mean simply mean that it isn't handled
as an error, but as a separate status "GIOStatusAgain".

We try to keep a clean distinction between error reporting
mechanisms for:

 - Programming errors (Done via g_warning/g_critical)
 - Error conditions indicating something has gone wrong, 
   that typically should be reported back to the user
   with an expressive message, but sometimes can be
   handled by a program. (GError: relatively expensive
   to set, but includes a very descriptive string.)
 - Non-error conditions. 

EGAIN falls into the last category. 

Regards,
                                        Owen