GNOME Bugzilla – Bug 731781
GLib-Critical: g_main_context_wait
Last modified: 2014-06-24 15:04:50 UTC
Hi I am not the VisualGST/GNU Smalltalk developer (just a user) but I discovered the following: (gst:7558): GLib-CRITICAL **: WARNING!! g_main_context_wait() will be removed in a future release. If you see this message, please file a bug immediately. (ip 8)DLD class>>#library:getFunc: running VisualGST 0.8.0 with GNU Smalltalk 3.2.4 on XUbuntu 14.04 - installed from XUbuntu Software Centre using their default PPA. I shall also try to file this with them. Kind regards Mark
hi Marvin, Thanks for this report. What version of smalltalk are you using? It appears that the use of g_main_context_wait() was removed by a commit in 2011: https://github.com/bonzini/smalltalk/commit/c5d608d91f8272ef73586c246ba86cfc0aaa08ce Even still, there is reason to be cautious here as not to break older versions. I've cc:'d Paolo Bonzini to this report. Paolo: can you provide some additional insight as to what you were trying to accomplish with that code? It looks like you don't use the condition variable at all. Did you only create it so that you had something to pass into that function? Would it be fine if we just ignored it?
> Did you only create it so that you had something to pass into that > function? Would it be fine if we just ignored it? Yes. g_main_context_acquire works just fine. The idea was to do prepare/query in one thread, poll in another, check/dispatch in the first. This was fine on Unix, but didn't work out on Windows due to Win32 limitations that GTK+ inherits. I don't remember why I didn't use g_main_context_acquire from the beginning, but the current solution does use it. :) It's been a while since the last stable release of GNU Smalltalk, but indeed the current code doesn't have this problem. There's no bug in glib.
I'd still like to make sure that the old version of smalltalk that calls this function will continue to work going forward. Would it makes sense for you if we just ignored the passed-in 'cond' variable in future versions of this function?
It would work for GNU Smalltalk. I never treated the condvar as anything but a glib implementation detail.
Great. Thanks for the information. This is what I was planning to do anyway. If we see any more of these reports, we can duplicate them to this bug. Thanks for reporting this, Marvin.