Linked by Thom Holwerda on Sun 23rd Dec 2007 21:11 UTC, submitted by Kaj de Vos
Thread beginning with comment 293288
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
More News »
Sponsored Links



Member since:
2005-07-06
I think that the locking/ordering of events in the multiple queue design you're suggesting must be quite hard:
Say Window A is selected at the beginning.
a-A mouse event select Window B.
b-A key is pressed.
Depending whether a or b occurred first, the key pressed event must be sent to Window A or B.
So these queue must sometime be synchronised carefuly..
I wonder how BeOS worked, with one queue or with multiple queues?
While I don't know if a different thread&queue to handle each device is interesting, I think that a different thread in the GUI server for each client application makes sense as this simplify the multiplexing of clients: currently an application even if low priority may flood the X server, making the higher priority application appear less responsive than it ought to..
With a different thread in the X server for each client app, maybe the OS scheduling could solve this issue, of course there is still the risk of a priority inversion caused by shared resource (and as the videocard itself is shared, it's not truly possible to avoid sharing)..