win32 patch dbus_watch_get_handle patch
ralf.habacker at freenet.de
Sat Jun 16 12:09:12 PDT 2007
Havoc Pennington schrieb:
> Ralf Habacker wrote:
>> Any problems with this patch ?
> I had a bunch of comments in
> https://bugs.freedesktop.org/show_bug.cgi?id=9334 that Peter
> mentioned, those all remain it looks like.
> - there should not be any dbus-specific fd-thingy, only sockets or
you wrote in 
"Remember we have no cross-platform idea of a file handle. "
I remember that this statement wasn't accepted by the windows porter.
file acces using the c runtime api with open/write/read/close is daily
work for many developers and it already used in the windows port of
dbus. Porting all file io using the win32 files api
(CreateFile/WriteFile/...) gives no benefit yet. There are more
important porting task as this.
So why should this be an important porting task ?
Is DBusFile intended as cross-platform file io class ? This would be
understandable for me. whatever the win32 implementation either c
runtime or win32 api DBusFile would be the public class.
> - internal functions should be in internal headers and
> underscore-prefixed, not in public headers with #ifdef
> - dbus_watch_get_fd() should probably return -1 on Windows
> (i.e. the DBusWatch API should work like connection_get_unix_fd
> and connection_get_socket, watch_get_fd does not have
> unix in the name for historical reasons but should work like
> it did)
Then i suggest to define a new functions dbus_watch_get_unix_fd()
beside the given one and mark dbus_watch_get_fd() as deprecated. Why not
defining a DBUS_DEPRECATED which let's the compiler print a warning if
such a function is used.
#if defined(__GNUC__) && (__GNUC__ - 0 > 3 || (__GNUC__ - 0 == 3 && __GNUC_MINOR__ - 0 >= 2))
# define DBUS_DEPRECATED __attribute__ ((__deprecated__))
#elif defined(_MSC_VER) && (_MSC_VER >= 1300)
# define DBUS_DEPRECATED __declspec(deprecated)
> Once the API is correct, I think you'll find that dbus-mainloop.c
> breaks on Windows, because in there we are relying on the broken unix
> emulation hack of an internal "file descriptor" object.
> dbus-mainloop.c is really a part of the bus daemon, not libdbus, and
> thus can't use weird internal fake descriptors.
> The solution to this is to change the abstraction boundary in
> dbus-mainloop.c so it does not have to deal with the socket/handle/fd
> directly but can delegate doing so to the sysdeps-win.c and
> sysdeps-unix.c files. One way to think of this is that _dbus_poll
> should probably be in sysdeps-unix.h instead of pretending to be a
> cross-platform API.
What hinders you to do so for the unix part ? The windows part would
works as before and when there is time the porter can follow your new
unix implementation. I believe that this would be much easier as
starting with the windows side. There are simply too many traps which
re quires a very deep internal knowledge not to trap into. :-)
More information about the dbus