nanogui: api:from client to server!!!!
Subject:
Re: [nanogui] api:from client to server!!!!
From:
Alex Holden ####@####.####
Date:
10 Jul 2002 10:43:36 -0000
Message-Id: <3D2C0E68.8000900@linuxhacker.org>
wangzhenyuan wrote:
> Take GrSelectEvents() for example ,first
> call AllocReq(SelectEvents),equal to call
> NxAllocReq() with "nxSelectEventsReq" as
> parameter ,at the comment of nxAllocReq(),
> it tells to alloc request buffer,look at
> this two line:
> if(reqbuf.bufptr + aligned_len >= reqbuf.bufmax)
> nxFlushReq(aligned_len,1);
> nxFlushReq() realloc space for Reqbuf.buffer ,
> and send the content of Reqbuf.buffer to
> server??? I haven't seen any data be put
> in ,but if not how does client sent event
AllocReq() returns a pointer to the allocated request structure and the
Gr*() function fills out the parameters. At some later point,
nxFlushReq() will be called because one of the following happens:
a. The user explicitly calls GrFlush().
b. The user calls a Gr*() function which returns a value, which calls
GrTypedReadBlock(), which flushes the event queue before waiting for the
server to return the result of the function it's just placed on the end
of the queue.
c. An AllocReq() requests more space than currently remains free in the
queue.
nxFlushReq() writes the data in the current queue to the server using
nxWriteSocket() (ignore the shared memory stuff for now) then makes sure
that the buffer is big enough to hold the next request and if not,
increases its size.
In the case of an nxAllocReq(), the header of the request isn't filled
out until after the possible call to nxFlushReq() so the request it's
allocating at the time won't be flushed until after it returns and the
function parameters are filled in.
> to sever?? and how does server receive the
> event and deal with it? I have read the
> fuctions GrSelectEventsWrapper() in srvnet.c
> and GrSelectEvents() in srvfunc.c ,but I don't
> understand how they get the client event.
After the client has written the data to the server, the server's main
select() loop will exit with the appropriate FD marked, causing
curclient to be set to the address of the client structure associated
with that client and GsHandleClient() to be called with its ID.
GsHandleClient() (in srvnet.c) reads the data from the client, works out
the address of the parameter data, and uses the function number as an
index into the GrFunctions[] array to call the appropriate wrapper
function. The wrapper function then extracts the parameters from the
parameter data, calls the server side version of the function (usually
located in srvfunc.c), and if necessary writes the result of the
function call back to the client. Some of the functions also have data
blocks that are filled in by the called function which also need sending
back to the client.
--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer
