solution to -> Re: adding fifo input to the main glib2 loop

[Ben Martin <monkeyiq users sourceforge net>]

After chatting on IRC and having owen looking at various things and
helping me on this issue I felt it would be nice to post extracts here
so that other folks looking at the same issue might find them here
later.

It turns out that after you have read() all the data from the fifo fd
glib2 gets POLLHUP and will keep spinning at 100% CPU while the HUP
condition is true on that channel.

<owen> monkeyiq: In a quick look at the kernel, doesn't look possible to
suppress the HUP, you'll probably just need to close the fd and open the
fifo again
<owen> monkeyiq: Well, there would be one trick -- you get the HUP when
there are *no* writers, so if you open the fifo read-write not
read-only, there will always be one writer, and you'll never get a HUP
<owen> monkeyiq: But I'm not sure of all the consequences of that. Unix
domain sockets just have a lot better semantics :-)

Since I am just using the fifo to read small chunks of scheme from the
user I unlink() and mkfifo after the scheme has been read (and
close/remake the g_io stuff).

Hopefully owens info can go on and help other folks in the future. If I
find a way to clear HUP then I'll post a followup msg to this one.


On Fri, 2002-09-06 at 22:57, Paul Davis wrote:
> >Hi,
> >  I have an app that mkfifo()s && open()s and then attaches a
> >g_io_channel to the fd. The basic idea is that clients can drop scheme
> >code to a fifo for the app to execute, thus the server only reads the
> >pipe and clients should only write it.
> >
> >I have this working with one catch, after the first command is read
> >(first callback instance) the app itself goes to 100% CPU use. Other
> >commands get through fine but from a break && bt it seems that glib2 is
> >churning on some property of the fd (the break always stops in glib2s
> >select (or poll, cant remember which it was)).
> >
> >Is there some condition that I must set or other thing required to
> >monitor fifos? Or some app that folks know of that does fifo IO from the
> >main loop.
> 
> there isn't anything extra. but are you sure you read *all* the data
> that was available from the FIFO? is it possible that select/poll
> believes there is still data available, and is repeatedly calling your
> callback? 
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
> 
-- 
-----------------------------------------------------
http://witme.sourceforge.net/libferris.web/