Re: GIOChannel missing binary mode?



From: 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 :-)

You're blocking on a call to read(), which is trying to fill up
the read buffer of the GIOChannel. Setting the channel nonblocking
just sits in your busy loop in wire_read(), though, so I'm not
sure why setting the channel unbuffered fixed it. Setting the channel
both unbuffered and nonblocking works, but repeatedly gives the message

gimp (pid:2593): LibGimpBase-WARNING **: gimp: wire_read(): error: No child processes

I'm not completely sure what's happening here.

Ron Steinke




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]