nanogui: Thread: API with point as parameter!


[<<] [<] Page 1 of 1 [>] [>>]
Subject: API with point as parameter!
From: "wang" ####@####.####
Date: 25 Jul 2002 14:12:19 -0000
Message-Id:

Greg,Alex!
 
   From former mail ,Alex has described how 
an API be called from client to server,if 
the API is called with no paramiter or some
simple paramiters,It can be transported by
socket very well,but some other API ,such as 
GrGetNextEvent(GR_EVENT *ep),the parameter is
a point,as known to all ,different process has 
different virtual address,how do you implement
this kind of API? 
  Take GrGetNextEvent(GR_EVENT *ep) for example,
the final aim is to get some events and fill 
them into the structure *ep which is in the 
client address space,but when the real fuction 
run in server address space ,how can it fill 
events information into the structure in client
address space?
 				
  Need you help!
        wang
####@####.####
          2002-07-25



Subject: Re: [nanogui] API with point as parameter!
From: Alex Holden ####@####.####
Date: 25 Jul 2002 15:15:05 -0000
Message-Id: <3D4012CC.8070707@linuxhacker.org>

wang wrote:
> GrGetNextEvent(GR_EVENT *ep),the parameter is
> a point,as known to all ,different process has 

Careful with terminology, a point is something quite different to a pointer.

> different virtual address,how do you implement
> this kind of API? 

You transfer the data over the socket to a memory block at the other
end. There is always some way to either know in advance or calculate at
call time how large the block of data to transfer is.

> client address space,but when the real fuction 
> run in server address space ,how can it fill 
> events information into the structure in client
> address space?

Okay, here goes:

When GrGetNextEventTimeout() is called (possibly via GrGetNextEvent()),
GrPrepareSelect() is called which allocates a GetNextEvent request and
flushes the queue. That causes the GrGetNextEventWrapper() in srvnet.c
to get called which sets a flag in the client structure indicating that
the client is waiting for events. When the server gets back to its core
function, GsSelect(), it goes through the list of clients looking for
clients which are both waiting for events and have events queued to be
sent to them. For each one it finds, it calls
GrGetNextEventWrapperFinish() in srvnet.c which writes the event
structure to the client over the network socket. The client does this:
GrTypedReadBlock(ep, sizeof(*ep),GrNumGetNextEvent); which reads the
event into the user-supplied event structure (the size is fixed because
GR_EVENT is used which is a union of all the GR_EVENT_* structures).

That's something of a simplification. See the source code for full details.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.