_dbus_write/read/poll etc and regular files

[Tor Lillqvist]

Havoc Pennington writes:
 > Another approach maybe is:
 >  typedef struct
 >  {
 >    DBusStreamType type; /* DBUS_STREAM_SOCKET, DBUS_STREAM_FILE, etc. */
 >    int value;
 >  } DBusStream;
 > 
 > And have _dbus_poll (or _dbus_wait_for_multiple_streams()) take one of
 > those instead of just an fd... then in the win32 implementation could
 > you unpack which descriptors are files and which are sockets, and
 > construct a WaitForMultipleObjects() call that can wait on both at once?

Yes but no ;-) It's more or less impossible to do select()-like wait
on a random C file descriptor. Well, nothing is impossible of course,
but it will take a lot of work and debugging, and the code will be
rather differently structured from what's used on Unix. Restricting
yourself to sockets makes for more elegant code, and increases code
reuse and/or sharing of code paths with Unix.

 > I don't know if all this abstraction is worth it though if right now we
 > are pretty much always using sockets. Why not just take any usage of fds
 > with files and wrap it in specialized functions inside dbus-sysdeps that
 > use write() or whatever directly, and then declare that the exported fd-
 > handling functions are sockets only - maybe rename them with "socket" in
 > the name.

Sounds ideal to me.

 > > But it would be simpler if I would know that only sockets need to
 > be > handled, this extra layer could then be dropped.
 > 
 > Ah, I guess you've already done some of the abstraction. My main
 > suggestion would be that if you do the abstraction work, make it a
 > little bit higher level (e.g. create a stream object or something,
 > adjust the API of poll(), whatever, so it's really abstracting things
 > rather than wedging it all into the UNIX API).

Well, when I started on the abstraction, I hadn't yet realized that
sockets pretty much are all that is used in D-BUS and that only the
print-address and print-pid functionality uses dbus_write to random
file descriptors. I wouldn't mind at all to revert the abstraction and
document and rename the fd-handling API to be for sockets only, as you
said earlier.

 > I realized this morning that yesterday's changes probably hosed you
 > pretty badly, sorry about that, I wasn't thinking.

Nothing too bad, it's OK now.

--tml