win32 patch dbus_watch_get_handle patch

[Ralf Habacker]

Havoc Pennington schrieb:
> Hi,
>
> 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.
[1]
> - there should not be any dbus-specific fd-thingy, only sockets or
>   HANDLE
you wrote in [1]
"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_COMPILATION
> - 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)
#endif


>
> 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. :-)

Ralf