|
From: <tim...@en...> - 2006-07-18 19:23:12
|
Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
> =20
>> Dave Denholm wrote:
>>
>> =20
>>> Ah - tell you what - there is one thing that is timing dependent.
>>>
>>> When you acquire a selection, you're supposed to give a
>>> timestamp. That is a server time, and it usually comes from the X
>>> event that triggered the action to acquire the selection. But gnuplot
>>> doesn't have such an event. IIRC, we use "currenttime" for that, but
>>> that isn't a real time.
>>> =20
>>> =20
>> Hmm. I wrote the code just a few months ago to provide this timestamp.=
I=20
>> took the time as plot->time. I realise now that this time is only=20
>> updated at a button release event, and put to 0 at each "record", so i=
f=20
>> the user doesn't click on the window this timestamp may have a useless=
=20
>> value.
>> =20
>
> Could have been a problem. But I eventually whittled things down to th=
e one problem Dave is keen to. I did notice that the client used to call=
a XA_TIMESTAMP selector request. But now it no longer does. Perhaps th=
at was an issue (that X could resolve with the XA_TIMESTAMP property requ=
est), and now has gone away.
> =20
Well, X itself does not call XA_TIMESTAMP, but other applications that=20
check for the content of the clipboard/selection like klipper. Without=20
XA_TIMESTAMP, klipper would infinitely retrieve the pixmap provided by=20
gnuplot, even if it did not change.
But that's not the race condition you're talking about, right ? I must=20
admit that I am a little lost in this thread. Can you repeat what you're=20
trying to solve/achieve ?
I think that Dave was probably talking about this=20
(gplot_x11.c:5924:export_graph):
XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime);
where we indeed use CurrentTime which is definitely not the time when=20
the event was triggered. Could be interesting to change CurrentTime to=20
plot->time, or rather :
(!plot || !(plot->time)) ? CurrentTime : plot->time
Best regards,
Timoth=E9e
|