Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
- From: Ryan Lortie <desrt desrt ca>
- To: David Zeuthen <david fubar dk>
- Cc: mclasen redhat com, gtk-devel-list gnome org, Havoc Pennington <havoc pennington gmail com>, Robert McQueen <robert mcqueen collabora co uk>
- Subject: Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
- Date: Sat, 31 Oct 2009 17:27:47 -0400
On Tue, 2009-10-20 at 11:17 -0400, David Zeuthen wrote:
> So how about something like 1. and 2. below? We'd put
>
> g_dbus_connection_get_handle_for_unix_fd()
> g_dbus_connection_set_handle_for_unix_fd()
I was actually thinking that we could introduce a GDBusFDSet:
gint g_dbus_fd_set_add_fd (gint fd) {
list_of_fds[fd_count] = dup (fd);
return fd_count++;
}
gint g_dbus_fd_set_get_fd (gint index) {
return dup (list_of_fds[index]);
}
g_dbus_fd_set_finalize () {
foreach (fd in list_of_fds) close (fd);
}
You'd add fds to that and get ints back (starting at 0 per the set).
Then when sending the dbus message you'd give the GVariant and the
DBusFDSet to the appropriate function.
var fd = open("file");
var fdset = new FDSet ();
var message = new GVariant ("(sh)",
"hello world",
fdset.add_fd (fd));
g_dbus_proxy_invoke_with_fds (proxy, "Foo", message, fdset, ...);
When receiving messages, you get a DBusFDSet handed to you in the event
that there were file descriptors (or just %NULL in case not).
The fds held in the GDBusFDSet are closed when the set is finalized.
There is no doubt about who owns which fd in this case -- and in the
case you elect to ignore fds that were sent to you then everything is
still cleaned up properly.
We could also have _steal() and _give() API variants. _steal would take
the fd out of the set (so the set no longer owns it, no longer closes
it) and _give would let you transfer ownership of an fd into the set --
we save a few syscalls that way in a few cases, I guess.
btw: I don't know if passing HANDLE on Windows is supported (and I would
guess not). Passing a G[Input|Output|IO]Stream is certainly not
supported (in a portable way, anyway).
Cheers
[
Date Prev][Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]