Diego Zuccato writes: > Is there a reason that makes useful to have two distinct calls for > different platforms instead of a single g_io_channel_get_fd() that works > across platforms? When the GIOChannel API was designed, it was not yet known to what extent it would be similar across platforms. And in any case, the things you get from g_io_channel_unix_get_fd() and g_io_channel_win32_get_fd() can not in general be handled the same way on Unix and Win32, so having different function names is rather natural. (You cannot read() and write() a SOCKET on Windows, for instance. And taking into consideration how watches on GIOChannels for fds is implemented on Windows (with separate threads for each watched channel, that sits blocking in read()), you can't have your code calling read() on a fd that has a GIOChannel that is being watched either. You should use g_io_channel_read().) > Shouldn't Glib/Gtk/etc be ABSTRACTION libraries? Not really. If GLib would want to be a total abstraction library also for file and network I/O, with all platform differences hidden away, then it would have to provide a complete file and socket I/O layer. I.e. you would have to open files and sockets also through GLib functions. It would essentially be a re-implementation of large parts of Mozilla's NSPR. --tml _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
