I solved the problem by not exiting the handler function, but instead locking it on a mutex, that is then released by the asynchronous callback. This takes care of the problem of the socket being released, as it is still the same function replying.
Now I have to figure out how to decline any connections arriving from a a non loop-back host. Dov On Sun, Nov 20, 2011 at 20:45, Dov Grobgeld <[email protected]> wrote: > I'm working on a jsonrpc server interface for glib and gio. I based my > interaction with gio on the gio/tests/echo-server.c example and everything > is working fine as long as the handler() - the function connected to by the > "run" signal - is sending back the response to client. > > But I got stuck on how to implement an asynchronous scenario where I don't > want the handler to write the answer back to the socket, but I would like > the handler exit without writing a reply and have another routine send back > the answer. A use case would be a gui application that receives a request > to prompt the user to do some interaction and then returns the choosen > action in the response. In such a case I would like to hand over the socket > connection from the handle to another function through and whenever the > reply it should be written to the connection. > > Unfortunately this scenario does not work with handler(). It appears that > the socket connection is destroyed on the exit of the handler() function. > Is there any way of preventing this? Or is there another more low level > interface to gio that I can use instead? > > (I wrote something similar several years ago with gnet and it worked much > better as the gnet client never closes the socket implicitely, so I had no > problem passing the connection aronud before I replied to the socket.) > > Thanks! > Dov > >
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
