'Re: gio, GSocketService, and connection hangup'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: gtk
Subject: Re: gio, GSocketService, and connection hangup
From: Dov Grobgeld <dov.grobgeld () gmail ! com>
Date: 2011-11-21 20:51:33
Message-ID: CA++fsGHTA8GOn2q2oXPd8PfoJWPLNJ7bVAaG8T4S6uM7ow8hcA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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 <dov.grobgeld@gmail.com> 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
>
>

[Attachment #5 (text/html)]

<div dir="ltr">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 <div \
class="gmail_quote">On Sun, Nov 20, 2011 at 20:45, Dov Grobgeld &lt;<a href="mailto:dov.grobgeld@gmail.com">dov.grobgeld@gmail.com</a>&gt; \
wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div dir="ltr">I&#39;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 \
&quot;run&quot; signal - is sending back the response to client.

But I got stuck on how to implement an asynchronous scenario where I don&#39;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?

<br>(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.)<br>

<br>Thanks!<span class="HOEnZb"><font \
color="#888888"><br>Dov<br><br></font></span></font><div></div></div> \
</blockquote></div><br><div style="display: none;" id="divCleekiAttrib"></div></div>

_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

[prev in list] [next in list] [prev in thread] [next in thread] 