Before the latest pull request I sent in, xclip differentiated requestors based solely on the Window ID number. Since X reuses the number for the next client immediately upon it being released, collisions were almost inevitable.
My changes helped to ameliorate that somewhat by doing two things:
A BadWindow error is caught and used to remove invalid requestors. (Hopefully before their IDs are reused).
The Property atom is also used to identify requestors.
But, this is still no guarantee. For example, if the same program were to run twice quickly the second instance could start before a BadWindow error occurs.
It is not immediately obvious to me from the ICCCM what characteristics should be used to make sure requestors are uniquely identified. Here is what I believe is the pertinent section:
"If the owner receives more than one SelectionRequest
event with the same requestor, selection, target, and
timestamp, it must respond to them in the same order
in which they were received.
It is possible for a requestor to have multiple
outstanding requests that use the same requestor
window, selection, target, and timestamp, and that
differ only in the property. If this occurs, and one
of the conversion requests fails, the resulting
SelectionNotify event will have its property argument
set to None . This may make it impossible for the
requestor to determine which conversion request had
failed, unless the requests are responded to in order."
(Note: This bug is only about the need for requestors to be uniquely differentiated. I do not know if the need for "responding in order" to requests is an issue given that this is a single-threaded server, but it should probably be looked into. Particularly, could there be an issue if two different INCR requests are started and the second one is sending less data over a faster network?)
Before the latest pull request I sent in, xclip differentiated requestors based solely on the Window ID number. Since X reuses the number for the next client immediately upon it being released, collisions were almost inevitable.
For example: window1% ./xclip -debug < 1.1M.jpg window2% ./borked # Closes connection before finishing. window2% ./xclip > foobar # Reuses broken connection, fails.
My changes helped to ameliorate that somewhat by doing two things:
But, this is still no guarantee. For example, if the same program were to run twice quickly the second instance could start before a BadWindow error occurs.
It is not immediately obvious to me from the ICCCM what characteristics should be used to make sure requestors are uniquely identified. Here is what I believe is the pertinent section:
(Note: This bug is only about the need for requestors to be uniquely differentiated. I do not know if the need for "responding in order" to requests is an issue given that this is a single-threaded server, but it should probably be looked into. Particularly, could there be an issue if two different INCR requests are started and the second one is sending less data over a faster network?)