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 767730 - Low priority source revents value coming wrongly to application
Low priority source revents value coming wrongly to application
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: mainloop
2.38.x
Other Linux
: Normal major
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-06-16 12:48 UTC by madana gopal
Modified: 2018-05-24 18:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Code changes for the described scenario (4.10 KB, text/plain)
2016-06-16 12:51 UTC, madana gopal
Details

Description madana gopal 2016-06-16 12:48:02 UTC
When we have both low priority and high priority source event landing simultaneously with revents set to 1 in poll(), low priority event is ignored in check() function. 

At the start of next loop cycle, prepare() saw the revents value of low priority source as 1 (got in previous cycle) and set its ready flag.But this is not processed.  revents of all the sources is set to 0 in query() function before poll(). poll() happened, at which revents of low priority source is coming as 0. At this time, only ready flag set by prepare() at the start of loop is considered and current revents is sent to application through dispatch().

This looks inconsistent, as ready flag is set by previous poll(), but revents of current poll is sent.
Comment 1 madana gopal 2016-06-16 12:51:53 UTC
Created attachment 329900 [details]
Code changes for the described scenario

The number of ready descriptors to be processed is got from prepare() function. And this value is used to process the pending sources, before going to next poll(). Tested and couldn't see any performance problem with this.

Please review the same.
Comment 2 Emmanuele Bassi (:ebassi) 2016-06-23 14:04:44 UTC
Please, do not play with the Bugzilla priority fields — they are not for you to set.

Also, it's bad form to add random people to the Cc list of a bug.
Comment 3 madana gopal 2016-06-23 18:37:25 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #2)
> Please, do not play with the Bugzilla priority fields — they are not for you
> to set.
> 
> Also, it's bad form to add random people to the Cc list of a bug.

ok, sorry.
Comment 4 madana gopal 2016-06-23 18:38:33 UTC
(In reply to madana gopal from comment #3)
> (In reply to Emmanuele Bassi (:ebassi) from comment #2)
> > Please, do not play with the Bugzilla priority fields — they are not for you
> > to set.
> > 
> > Also, it's bad form to add random people to the Cc list of a bug.
> 
> ok, sorry.

could anybody, please review this and share the comments
Comment 5 madana gopal 2016-06-27 23:47:20 UTC
Could anybody, please review and share comments
Comment 6 madana gopal 2016-08-11 19:42:55 UTC
Could anybody, please review and share comments. I am waiting for the suggestions.
Comment 7 GNOME Infrastructure Team 2018-05-24 18:57:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1174.