GNOME Bugzilla – Bug 658020
GSource for a single GPollFD
Last modified: 2013-01-15 19:09:52 UTC
Rumour has it that lots of people would find a GSource that polls a single GPollFD very handy. gboolean (*GPollFDFunc) (GPollFD *poll_fd, GIOCondition revents, gpointer data); /* note: makes copy of GPollFD structure */ GSource * g_poll_fd_source_new (GPollFD *poll_fd); guint g_poll_fd_add (GPollFD *poll_fd, GPollFDFunc func, gpointer data); guint g_poll_fd_add_full (gint priority, GPollFD *poll_fd, GPollFDFunc func, gpointer user_data, GDestroyNotify notify); I'll do that now, using the new GSource API from bug #657729.
Sounds good to me; I would crosslink in the docs between this and g_io_create_watch(); mention that this is the new (better) way to make watches for a file descriptor.
(In reply to comment #1) > Sounds good to me; I would crosslink in the docs between this and > g_io_create_watch(); mention that this is the new (better) way to make watches > for a file descriptor. Well, on UNIX maybe, but GPollFD doesn't take file descriptors on Windows, so you still need to use a GIOWatch (or better yet, libgio) if you want to be portable. Which leads to the question: should this be a UNIX-only API, or should it document that on UNIX it takes a file descriptor, and on Windows it takes a waitable HANDLE? (In reply to comment #0) > gboolean (*GPollFDFunc) (GPollFD *poll_fd, > GIOCondition revents, > gpointer data); If the callback function includes the revents as a parameter, then is there any point in using a GPollFD at all? Just have the caller pass a file descriptor and an events mask, and g_poll_fd_add() can create the GPollFD for you.
I dropped the revents field while I was writing the patch specifically because it was redundant. GPollFD makes sense on Windows. We have g_cancellable_make_pollfd() for example. If you take the result of that function and create a pollfd source from it, then it would work.
Created attachment 195448 [details] [review] Add a GPollFD source
(In reply to comment #3) > GPollFD makes sense on Windows. We have g_cancellable_make_pollfd() for > example. If you take the result of that function and create a pollfd source > from it, then it would work. But we only have that function because we belatedly realized that g_cancellable_get_fd() wasn't portably usable. Anyway, I wasn't saying it didn't make sense on Windows, I was saying that it doesn't work with "file descriptors" on Windows
ahh. I see what you're saying. I wonder if maybe we should change the structure definition of GPollFD on Windows to actually contain a field called 'handle'... This is technically an API change, but it would only impact people whose code is already broken... Then we could advertise that it was a meaningful thing to use.