After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 332030 - mainloop starts eating cpu if pipes are broken
mainloop starts eating cpu if pipes are broken
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: mainloop
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2006-02-21 13:10 UTC by Benjamin Berg
Modified: 2006-02-21 15:02 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch that removes the broken sources (6.72 KB, patch)
2006-02-21 13:16 UTC, Benjamin Berg 		none Details | Review

Description Benjamin Berg 2006-02-21 13:10:18 UTC 
What happens is the following:

 1. app adds a watch with g_io_add_watch (channel, G_IO_IN, some_func, some_data) for a pipe to a subprocess.
 2. The subprocess dies/gets killed, so that the pipe has an status G_IO_HUP
 3. poll always returns immediatly because the pipe is broken
 4. the application does not get notified of the broken pipe, because it is only watching for input. Which means that the channel is not destroyed, and the poll will return immediatly again.

I'll attach a patch, that tries to prevent this loop, by destroying sources, that the application can't ever get notifications for. This will prevent the mainloop from going into a loop.

See also the gnome-vfs bug 332028.
Comment 1 Benjamin Berg 2006-02-21 13:16:02 UTC 
Created attachment 59846 [details] [review]
patch that removes the broken sources

This patch removes obviously broken sources from the mainloop. I did some guesswork for the win32 part so it is untested.
Comment 2 Tor Lillqvist 2006-02-21 13:21:31 UTC 
Surely you realize that changing the return type of the check method in GSourceFuncs would break API?
Comment 3 Owen Taylor 2006-02-21 15:02:53 UTC 
The app has to watch for HUP | IN.