[<<] [<] 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 [>] [>>] |