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 687988 - should not use guint-based GSource APIs
should not use guint-based GSource APIs
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-09 14:25 UTC by Dan Winship
Modified: 2012-11-12 15:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Dan Winship 2012-11-09 14:25:32 UTC 
memory-managed bindings should use the GSource*-based GSource APIs, not the guint-based ones, since

  a) in some programs, the IDs may eventually overflow and get reused
     (bug 687098)

  b) g_source_remove() is O(n), whereas g_source_destroy() is O(1)

AIUI python has bignums, so in theory you could just convert the GSource*s from pointers to integers and back, and so not change the public API at all. Although that would break refcounting of the GSource* so maybe you wouldn't want that.
Comment 1 Martin Pitt 2012-11-12 06:09:17 UTC 
Hey Dan,

I agree that in general that is a better idea. However, pygobject itself does not set up any event sources, it merely provides bindings to the GLib API. Where in pygobject's code did you see that?

Thanks!
Comment 2 Dan Winship 2012-11-12 11:43:43 UTC 
Ah, no, I didn't mean pygobject's own use, I meant that it should expose the GSource-based APIs as part of the pygobject API, so its consumers can use them rather than the guint-based ones.
Comment 3 Martin Pitt 2012-11-12 11:48:54 UTC 
In master we dropped all the static bindings, so it should actually be available now. Do you see a particular method which is still missing?

E. g. for g_idle_add() glib does not have a direct equivalent, but you can do g_idle_source_new(). You can do the same in Python with "GLib.Idle()" and attaching that to a context yourself, just as in C.
Comment 4 Dan Winship 2012-11-12 15:09:37 UTC 
ah, cool, I was basing this off comments in bug 687098, which apparently are about an older version of pygobject
Comment 5 Martin Pitt 2012-11-12 15:15:02 UTC 
Indeed; the correct handling of overflowing source IDs has been fixed in pygobject 3.4.2, and due to the removal of the static bindings it's not an issue any more in 3.7.x.