GNOME Bugzilla – Bug 744717
platform-demos: Add a page on writing GSource implementations
Last modified: 2021-07-05 10:53:45 UTC
Here’s a new page which discusses writing a custom GSource implementation, and more general topics about how GSources are shaped. One of the bigger things needing review and thought is the example code here. It is in two files: example-custom-gsource.c and test-custom-gsource.c. The latter #includes the former to unit test it, building a test-custom-gsource binary on `make check`. Currently, the CC command line for doing this is hard-coded (GNU Make style) in the Makefile.am, to avoid a hard dependency on a C compiler in the module (although, actually, this will cause the unit tests to fail if compilation fails). Do we want to add all the normal AC_PROG_CC stuff to gnome-devel-docs, or do we want something lighter-weight which happily succeeds the tests if no compiler is available?
Created attachment 297106 [details] [review] programming-guidelines: Add a page on writing GSource implementations This includes some example code which is discussed in the page. The code comes with its own test suite which it is #included into, and the test suite is run on `make check`. The rules for compiling the test suite are entirely manual at the moment to avoid introducing a dependency on a compiler to the gnome-devel-docs module. They could be changed to use more conventional automake support for building C programs.
I think that, as a whole, this strays beyond what the programming guidelines were conceived as, and into HowDoI territory. It is too specific to fit in with general programming guidelines. The content seems high quality, but the programming guidelines do not seem like the right place, so let's draw the (arbitrary) line at GMainContext (for which you already wrote a page). I certainly do not want to add a dependency on a C compiler.
Created attachment 297281 [details] [review] platform-demos: Add a page on writing GSource implementations This includes some example code which is discussed in the page. The code comes with its own test suite which it is #included into, and the test suite is run on `make check`. The rules for compiling the test suite are entirely manual at the moment to avoid introducing a dependency on a compiler to the gnome-devel-docs module. They cannot be changed to use more conventional automake support for building C programs, because the mere presence of a _SOURCES variable causes automake to require a C compiler for dependency generation.
Created attachment 297282 [details] [review] programming-guidelines: Remove FIXME from main contexts page The GSource page has been added to the platform-demos manual instead, since it’s a bit too specific to be in the general-purpose programming guidelines.
As discussed on IRC, let's put this page in the platform-demos instead, including an optional CC dependency during `make check` and `make distcheck`.
Review of attachment 297281 [details] [review]: Not really happy with this, but I do not see an alternative.
Review of attachment 297282 [details] [review]: OK.
Created attachment 297284 [details] [review] platform-demos: Add a page on writing GSource implementations This includes some example code which is discussed in the page. The code comes with its own test suite which it is #included into, and the test suite is run on `make check`. The rules for compiling the test suite are entirely manual at the moment to avoid introducing a dependency on a compiler to the gnome-devel-docs module. They cannot be changed to use more conventional automake support for building C programs, because the mere presence of a _SOURCES variable causes automake to require a C compiler for dependency generation.
Created attachment 297285 [details] [review] programming-guidelines: Remove FIXME from main contexts page The GSource page has been added to the platform-demos manual instead, since it’s a bit too specific to be in the general-purpose programming guidelines.
Thanks, pushed. Attachment 297284 [details] pushed as 59a8c23 - platform-demos: Add a page on writing GSource implementations Attachment 297285 [details] pushed as ed6a867 - programming-guidelines: Remove FIXME from main contexts page
I'm sorry I didn't notice this before, but I'm not subscribed to these bugs. This doesn't correctly document the modern way of using GSource, since 2.36. prepare and check functions should both be NULL, and g_source_set_ready_time() should be used instead. Feel free to ping/subscribe me about these sorts of issues in the future if you want me to give it a look over (instead of randomly noticing bugbot telling me that the bug was closed).
(In reply to Ryan Lortie (desrt) from comment #12) > I'm sorry I didn't notice this before, but I'm not subscribed to these bugs. Sorry, I should have CCed you. > This doesn't correctly document the modern way of using GSource, since 2.36. > > prepare and check functions should both be NULL, and > g_source_set_ready_time() should be used instead. How does that fit in with querying the GAsyncQueue length? Am I supposed to call g_source_set_ready_time(source, 0) on creating the source, and then check the queue length in dispatch()?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-devel-docs/-/issues/ Thank you for your understanding and your help.