GNOME Bugzilla – Bug 121345
Try to cover up POLLHUP portability differences
Last modified: 2013-11-24 01:48:44 UTC
This is a portability issue detected on AIX with gnome-session-save. If we run gnome-session-save with some pure X applications like xterm or xclock, gnome-session-save displays a warning message and after the "OK" hangs and never displays the OK dialog. Metacity is hanging too. The reason of this behaviour is that metacity has launched "metacity-dialog --warn-about-no-sm-support ..." to display the warning messages and is waiting to the end of this application. To detect the end, it has opened a pipe to this application and it is waiting that the pipe is broken. For it, a broken pipe is detected by POLLHUP in the revents field of poll(). BAD NEWS: broken pipe is not detected by POLLHUP on a lot of platforms... LOOK AT the very good analysis of Richard Kettlewell at http://www.greenend.org.uk/rjk/2001/06/poll.html The current behaviour of glib is the behaviour of linux: Linux 2.2.19 POLLHUP POLLHUP POLLIN but on my AIX box it is: AIX POLLIN POLLIN POLLIN I propose a patch that creates an intermediate behaviour for GLIB: GLIB POLLIN|POLLHUP POLLIN|POLLHUP POLLIN|POLLHUP this patch detects EOF on POLLIN and add POLLHUP to revents, so application can continue to wait to POLLHUP in all cases. prerequisite: - POLLHUP is detected only if POLLIN is set in events - application must read all data in pipe before glib can detect EOF and set POLLHUP in revents postconditions: - POLLHUP is ever sent to application on EOF (pipe, socket and even regular file) MOREOVER, I think g_poll() never set POLLHUP in revents.
Created attachment 19693 [details] [review] A patch to set POLLHUP in revents of poll() on POLLIN and EOF
This is an application bug - could you file a bug against metacity? The flags for g_io_channel_add_watch() are defined to be *exactly* the same as the flags for poll(), and have the same requirement to select for HUP|IN if you want to catch EOF. HUP|IN followed by a 0 length read for read() is the only sure way to catch EOF. One definite reasons this is needed is that poll() implemented in terms of select() doesn't have the ability to distinguish the EOF condition. GLib in fact contains a poll-on-select emulation code that is used if poll() isn't found, which has this same limitation. The ioctl(fds[j].fd,FIONREAD,&ret); trick is sort of interesting, so I'll leave this bug open for GLib. But I have definite concerns about: A) Portability. Does it really work in all cases where HUP isn't returned on EOF? B) Performance. It's a extra system call for every file descriptor that is readable on every iteration of the GLib main loop.
No comment... Created bug for metacity: http://bugzilla.gnome.org/show_bug.cgi?id=121376 Created bug for gedit/shell_output plugin: http://bugzilla.gnome.org/show_bug.cgi?id=121377
Any news about that proposition, should we consider that bug to be canceled/closed as other ones were opened ? Thanks. Jean-Pierre Dion
The fields above, severity=enhancement Target Milestone=future indicates the status here: - This is not a GLib bug - However, it might be a nice enhancement for the future to simplify things. - We don't expect to have to time to work on it for a while; if someone showed up with a patch, that woudld presumably shorten the timescale.
closing out decades-old bugs