Re: GIOChannel missing binary mode?

[Michael Natterer <mitch gimp org>]

Ron Steinke <rsteinke w-link net> writes:

> > From: Michael Natterer <mitch gimp org>
> >
> > Maybe GIMP's IO channel events are a bit more complex and trigger
> > something completely different :-)  If you want to test it, remove
> > the g_io_channel_set_buffered() from CVS gimp in app/plug_in.c and
> > libgimp/gimp.c and see what happens.
> >
> > (Maybe it's just an explicit flush() or something that's missing
> > to make it work in buffered mode...).
> 
> If the gimp has it's own read and write functions for the channel, this
> could be causing the problem. The gimp functions would (I'm guessing)
> use the old glib API functions, which know nothing about the buffers.
> If you want to mix the new glib API functions with the old API functions,
> you have to set the channel unbuffered. Otherwise, the old API functions
> will read the next data from the disk instead of from the buffer (with
> a similar problem with write).

I switched to g_io_channel_[read|write]_chars() completely for
reading/writing the pipe from the main app to plug-ins (on both
sides), so there is no old/new API mix on the pipe.

(We don't use GIOChannels for file IO).

> If this isn't the case, could you be more explicit by what you mean by "failing"?
> Do you mean "glib issues a warning" or "the iochannel functions return an error
> when they shouldn't (e.g. a conversion error for NULL encoding)" or
> "the data I read/write turns out to be garbage"?

Plug-in communication just blocks on the very first plug-in the GIMP
opens. This happens either on startup when the plug-ins are queried or
(in case they are all already registered) on the first extension GIMP
tries to start (namely script-fu). There are no warnings issued, it
just stops and waits for something.

So I simply switched off buffering because the current state of
gimp/app/plug_in.c isn't something that is fun to debug :-)

The plug-in stuff in scheduled for major overhaul anyway when we
switch to GParamSpec for plug-in arguments, so the read/write blocks
will maye happen again then.

I'll bring the topic up again once I understand this weird piece of
antique code better...  In the meantime a GIOChannel guru like you may
be able to find it within minutes (just comment out the set_buffered()
calls...).

thanks & bye,
--Mitch