Conference bulova::decw_jan-89_to_nov-90

Re: .0

>    1. What is REALLY the event serial number? Yes, I know, it determines
>    event order, but, if that's true, why is it possible to have two
>    events with the same serial number?
       
I'm sure a server person could give you a more authoritative answer on this,
but since I got burned by this I'd like to share what I learned.

Serial numbers are assigned to requests going from the client to the server.
As each request is put into the queue to be sent to the server, the client
increments a 32 bit serial number.  If I remember correctly, the server also
keeps a counter for each connection that it increments in synch with the
client.

If a request, such as XCopyArea (actually that's the Xlib routine; there's a
different name for the protocol request) generates one or more (server-
to-client) events such as GraphicsExpose, each event will be tagged with that
request's serial number.  That's why there can be multiple events with the same
serial number: they were all generated by the same request.

Here's the catch, though: the protociol passes only 16 bits of the serial
number, and Xlib in the client has to guess at the top 15 bits, based on
other events that it has recently received (or requests that it sent? -- I'd
have to go back and look at the code again).  In some cases the client guesses
incorrectly, and the application sees an event with an unexpected serial
number.

DECterm V2 uses NoExpose and GraphicsExpose events for synchronization with
the server, to limit the rate at which it does scrolling so that Hold Screen
will be more responsive.  Unfortunately, because of the problem I just
mentioned, sometimes it would block output waiting for an expose event, but
it never saw the serial number it was waiting for.  This mean that the window
was hung until the user did a Clear Communications.  This will be fixed
in V5.4.

>    2. I'm working with DECwindows on VMS, where MIT & VAX bindings
>    are available; and on ULTRIX?
    
The last I heard, both the MIT and VAX binding exist for VAX ULTRIX, but only
the MIT bindings exist for RISC (PMAX).

				-- Bob

Bob is right with one addition.  The serial number that comes back with an
event is the number associated with the last request that the server has seen
on that connection.

Burns

    Thank you, Bob & Burns, for your heaven-sent answers.
    But I have a little problem, yet.
    
    Have you ever seen the "Events" application? In this application
    I can choose an event on a window and, after producing the event,
    I can examine the event description (type, serial number, window,
    x, y and so on).
    
    When I choose MotionNotify event and I move the pointer in and out
    of the selected window, I note the large number of MotionNotify
    that generate.
    Sometimes, and not always, two consecutive MotionNotify have the
    same serial number.
    
    Thanks in advance for your kindness.
    Giulio

I have not seen that application, but all it means if the s/n values are the
same is that the server  did not receive any requests between generating the two
motion notifies.  Remember that on the client, everything is buffered.  It is
to some extent on the server as well.  Thus there is no guarantee of the
the sequencing among request streams, or among request vs event streams.  The
only guaranteed ordering is within a set of requests (or events).

Burns