[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
nano-X --> waiting_for_event
From: "Jonas Greutert" ####@####.#### Date: 29 Dec 2006 10:46:53 +0000 Message-Id: <F8CD2433E50BAB4AA9B818D1AE30CA3BBD9E17@GILA.netmodule.intranet> Hi I do not see the reason for some implementation specifics of the nano-X client server protocol. I.e. what is the reason that the server only sends events to the client on request and not as soon as there is an event? For testing I changed the code in srvmain.c as follows: Line 235 and line 650: curclient->waiting_for_event = TRUE; /* was FALSE */ That way, *no* GrPrepareSelect, i.e. AllocReq(GetNextEvent); GrFlush(); is required in the client. The client can simply do a select (on the nanox fd) and call GetNextEvent. Events are queued in the client socket. Now, the only thing that remains to be resolved is the select in _GrGetNextEventTimeout (client.c)... Basically, a new GetNextEvent has to be written that does not include a select statement (the select shall be outside of the nano-X client). Probably, GrServiceSelect is very near to what I would need. However, before I continue, I would like to get your feedback. Maybe I do misunderstand something here. Cheers, -- Jonas | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] nano-X --> waiting_for_event
From: "Greg Haerr" ####@####.#### Date: 14 Jan 2007 16:44:35 +0000 Message-Id: <1ab101c737fb$2b28c680$6401a8c0@winXP> > I do not see the reason for some implementation specifics of the nano-X client server protocol. I.e. what is the reason that the server only sends events to the client on request and not as soon as there is an event? The reason for this is that in order for things to be kept simple, there is no packet queuing mechanism in the client. Thus when a client requires certain data, it can't handle event data instead. Also, too much code is required to stop the server from blocking should a client not read its queue and the server write() blocks. The list goes on. For instance, when a client executes a GrGetXXX call, it requires that return data synchronously. > curclient->waiting_for_event = TRUE; /* was FALSE */ > That way, *no* GrPrepareSelect, i.e. AllocReq(GetNextEvent); GrFlush(); is required in the client. The client can simply do a select (on the nanox fd) and call GetNextEvent. Events are queued in the client socket. Now, the only thing that remains to be resolved is the select in _GrGetNextEventTimeout (client.c)... Basically, a new GetNextEvent has to be written that does not include a select statement (the select shall be outside of the nano-X client). The above code will work only when you KNOW that the client is in fact waiting for an event. If it executes a GrXXX call that requires other data, the system may become unsynchronised. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |