syntheticpp at gmx.net
Wed Sep 13 03:21:17 PDT 2006
I've uploaded a patch which renames the fd functions to *_socket.
All the file handling is now internal to unix/win files, and
the other code only uses the already available file/dir
functions of sysdeps.h.
But I don't knoow what to do with
void _dbus_fd_set_close_on_exec (int fd);
Is this also a socket-only function or is it also
used to close files?
The remaining _unix_ functions are only used in -unix.c files
and they are candidates for a sysdeps-unix.h header.
While doing the renaming I had the idea to change
_dbus_close(int fd, int) to _dbus_close(int *fd, int)
and to set *fd = -1 when the closing was successful,
so fd has a actual value.
Havoc Pennington wrote:
> Peter Kümmel wrote:
>> Looking at the code again, I see that a public file access
>> interface isn't necessary, at least when we don't move some
>> files back to sysdeps.c: Currently all relevant code
>> are in -win/-unix files.
>> Maybe dbus_create_file_exclusively() as public function is enough.
> Agreed, I was just thinking that also. We're overcomplicating this. We
> don't need read/write/close on files; we can just export stuff like
> and other high-level operations.
> You could try to just get rid of all uses of read/write/close on files
> (outside of -unix.c/-win.c), replacing them with functions like the
> above (first patch), then (second patch) rename read/write/close/poll to
> be read_socket, write_socket, close_socket. I think it would be fine to
> keep the socket as "int" instead of a DBusSocket, since it's an int on
> both platforms, and we won't have a file int in the api at all.
More information about the dbus