Xserver-spec: Delete DBE Idioms section
The code has been gone for a while Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
This commit is contained in:
parent
f4ba75a494
commit
903e0f6f0f
|
@ -1361,70 +1361,6 @@ The sample server implementation for these routines
|
|||
is in Xserver/os/util.c.
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>Idiom Support</title>
|
||||
<para>
|
||||
The DBE specification introduces the notion of idioms, which are
|
||||
groups of X requests which can be executed more efficiently when taken
|
||||
as a whole compared to being performed individually and sequentially.
|
||||
This following server internal support to allows DBE
|
||||
implementations, as well as other parts of the server,
|
||||
to do idiom processing.
|
||||
</para>
|
||||
<para>
|
||||
<blockquote><programlisting>
|
||||
|
||||
xReqPtr PeekNextRequest(xReqPtr req, ClientPtr client, Bool readmore)
|
||||
</programlisting></blockquote>
|
||||
If req is NULL, the return value will be a pointer to the start of the
|
||||
complete request that follows the one currently being executed for the
|
||||
client. If req is not NULL, the function assumes that req is a
|
||||
pointer to a request in the client's request buffer, and the return
|
||||
value will be a pointer to the the start of the complete request that
|
||||
follows req. If the complete request is not available, the function
|
||||
returns NULL; pointers to partial requests will never be returned. If
|
||||
(and only if) readmore is TRUE, PeekNextRequest should try to read an
|
||||
additional request from the client if one is not already available in
|
||||
the client's request buffer. If PeekNextRequest reads more data into
|
||||
the request buffer, it should not move or change the existing data.
|
||||
</para>
|
||||
<para>
|
||||
<blockquote><programlisting>
|
||||
|
||||
void SkipRequests(xReqPtr req, ClientPtr client, int numskipped)
|
||||
</programlisting></blockquote>
|
||||
The requests for the client up to and including the one specified by
|
||||
req will be skipped. numskipped must be the number of requests being
|
||||
skipped. Normal request processing will resume with the request that
|
||||
follows req. The caller must not have modified the contents of the
|
||||
request buffer in any way (e.g., by doing byte swapping in place).
|
||||
</para>
|
||||
<para>
|
||||
Additionally, two macros in os.h operate on the xReq
|
||||
pointer returned by PeekNextRequest:
|
||||
<blockquote><programlisting>
|
||||
|
||||
int ReqLen(xReqPtr req, ClientPtr client)
|
||||
</programlisting></blockquote>
|
||||
The value of ReqLen is the request length in bytes of the given xReq.
|
||||
<blockquote><programlisting>
|
||||
|
||||
otherReqTypePtr CastxReq(xReq *req, otherReqTypePtr)
|
||||
</programlisting></blockquote>
|
||||
The value of CastxReq is the conversion of the given request pointer
|
||||
to an otherReqTypePtr (which should be a pointer to a protocol
|
||||
structure type). Only those fields which come after the length field
|
||||
of otherReqType may be accessed via the returned pointer.
|
||||
</para>
|
||||
<para>
|
||||
Thus the first two fields of a request, reqType and data, can be
|
||||
accessed directly using the xReq * returned by PeekNextRequest. The
|
||||
next field, the length, can be accessed with ReqLen. Fields beyond
|
||||
that can be accessed with CastxReq. This complexity was necessary
|
||||
because of the reencoding of core protocol that can happen due to the
|
||||
BigRequests extension.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
|
Loading…
Reference in New Issue