> I'm not sure that it will ever support passing win32
> handles in the same way...
Nah, I assume it won't be necessary. To the extent it is possible to
pass Win32 HANDLES from one process to another, it uses a totally
different mechanism: The HANDLE is "duplicated" already in the source
process
On Wed, 2009-11-11 at 10:42 -0500, Ryan Lortie wrote:
> On Wed, 2009-11-11 at 09:31 -0500, David Zeuthen wrote:
> > Should probably define an abstract GDBusHandleSet interface and then
> > have a concrete GDBusUnixFdSet class (and possibly a GDBusWin32HandleSet
> > too) implement it.
>
> I'm not t
On Wed, 2009-11-11 at 09:31 -0500, David Zeuthen wrote:
> Should probably define an abstract GDBusHandleSet interface and then
> have a concrete GDBusUnixFdSet class (and possibly a GDBusWin32HandleSet
> too) implement it.
I'm not totally sure that this makes sense. The support that exists in
DBu
On Mon, 2009-11-09 at 11:29 -0500, Ryan Lortie wrote:
> > Hmm, I don't like this approach. It means you'd have to pass this
> > GDBusFDSet object around in code you use to build/parse the GVariant. In
> > particular, your proposed GTypeSerializer would need support for it.
> > That's problematic be
On Mon, 2009-11-09 at 08:21 -0500, David Zeuthen wrote:
> Sorry for the lag,
No problems :)
> Hmm, I don't like this approach. It means you'd have to pass this
> GDBusFDSet object around in code you use to build/parse the GVariant. In
> particular, your proposed GTypeSerializer would need suppor
Hey Ryan,
Sorry for the lag,
On Sat, 2009-10-31 at 17:27 -0400, Ryan Lortie wrote:
> 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
> btw: I don't know if passing HANDLE on Windows is supported (and I would
> guess not).
Sure it is. DuplicateHandle() can be used for this. I.e. a process A
that has the required access right (PROCESS_DUP_HANDLE) to two
processes U and V can take a HANDLE value valid in source process U
and dupli
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 (g
On Thu, 2009-10-15 at 14:02 -0400, Ryan Lortie wrote:
> On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote:
> > Yeah, I think we need to support this from the get-go.
> >
> > Anyway, at the end of the day, UNIX fds are just integers so if you
> > require that users (such as GDBus itself and a
On Thu, 2009-10-15 at 14:02 -0400, Ryan Lortie wrote:
> On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote:
> > Yeah, I think we need to support this from the get-go.
> >
> > Anyway, at the end of the day, UNIX fds are just integers so if you
> > require that users (such as GDBus itself and a
On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote:
> Yeah, I think we need to support this from the get-go.
>
> Anyway, at the end of the day, UNIX fds are just integers so if you
> require that users (such as GDBus itself and apps using GDBus) keep the
> fds alive until the method/signal ha
On Thu, 2009-10-15 at 10:54 -0400, Ryan Lortie wrote:
> >2. GVariant doesn't yet handle the new 'h' type (e.g. unix fd)
>
> Holy crap! This is insane! I had no idea that this was going on
> upstream -- I might have had something to say about it.
>
> It seems kind of unfortunate that the DBu
12 matches
Mail list logo
