ICCCM Compliance: Requestors need to be differentiated

[hackerb9]

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:

1. A BadWindow error is caught and used to remove invalid requestors. (Hopefully before their IDs are reused).
2. 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?)