Created attachment 342007 [details] [review]
bus: Add function to get the file descriptor of the bus

This is useful for integration with other event loops that work by
polling file descriptors. G_IO_IN will always be set whenever a message
is available currently.

Comment on attachment 342007 [details] [review]
bus: Add function to get the file descriptor of the bus

Looks fine to me, but just for comparison g_socket_get_fd() returns either an int or a HANDLE depending on the OS.

That's exactly why I went with GPollFD :) That contains an fd on non-Windows, and a HANDLE on Windows. We don't need different APIs then depending on OS.

Ok.

Does it work with bindings?

Do we maybe also need a gboolean return in case the bus has no fd? (I think only busses that are async-enabled have an fd?)

(In reply to Tim-Philipp Müller from comment #4)
> Ok.
> 
> Does it work with bindings?

Asking

> Do we maybe also need a gboolean return in case the bus has no fd? (I think
> only busses that are async-enabled have an fd?)

It will g_return_if_fail(), just like creating a bus watch would

(In reply to Sebastian Dröge (slomo) from comment #5)
> (In reply to Tim-Philipp Müller from comment #4)
> > Ok.
> > 
> > Does it work with bindings?
> 
> Asking

No. The alternative would be

a) gst_bus_get_fd() on non-Windows, gst_bus_get_handle() on Windows. And have the symbols either platform specific, or let them be there always and return something invalid on the wrong platform

b) platform specific return value (gint vs HANDLE)

c) return a gint64 always and require people to cast

Alternatively we just keep it as is and worry about this when someone actually needs it in bindings.

I don't know, it's all awkward :)

I'd say either

1) just go with the patch as-is for now, and mark it as (skip) for bindings. If someone wants to use it from bindings we can add _get_fd() + get_handle(), or

2) just add a _get_fd() for now, and if someone wants to use it on Windows we'll need to add a _get_handle() as well.

I'm leaning towards (2).

I prefer 1) because it's like the GstPoll API already does it, seems more consistent. I agree that for bindings we should just worry about that when someone needs it. We will then also have a better idea about the API requirements there.

Right. Reason I was leaning towards (2) is that we know it's going to work with bindings and we don't add a function that we know we'll have to replace with more functions in future anyway. I don't see GPollFd working for bindings in the near future, and I think we'll want separate functions for fd and HANDLE in any case when the time comes, everything else is just not right.

But if you want to go with (1) for starters that's fine too IMHO, doesn't really matter.

Attachment 342007 [details] pushed as c77f661 - bus: Add function to get the file descriptor of the bus