David Dawes is maybe the most active XFree86 developer and he is also the lead founder of the project. He works for Tungsten Graphics, which is the main company working on the XFree, DRI and Mesa codebases today. We are happy to host an interview with David, discussing the present and future of XFree86 project. Update: Still confused how a VSYNCed desktop look like? Read here.
Permalink for comment
To read all comments associated with this story, please click here.
Have you tried Local Domain sockets? Or perhaps implementing a stateful protocol over the connectionless IPC?
What, you think I was benchmarking against TCP sockets? Of course I was benchmarking against Unix domain sockets, and saw their performance to be 10%-50% better than Unix domain sockets, depending on the platform.
As to implementing any sort of protocol to remedy the connectionless nature of SysV message queues, I'd say this is a waste of time.
Eh? Did you try IPC_STATing the message queue and obtaining the pid of the last message (msg_lrpid)?
*COUGH*HACK*COUGH* I'd say a better solution would be to use a more thought out message passing mechanism such as Mach messaging.
The API offers quite a bit more flexability than sockets as well e.g. message priorities/types, persistence, etc. The Also, the atrocious API easily (and should be) be wrapped up into the equivalent of Xlib so the client would have no knowledge of the underlying IPC methods.
The problem arises precisely when you attempt to abstract SysV message queues. The queues expect the data buffer to be preceeded by a message type identifier. That means a great deal of nasty hacks to provide an abstract interface for zero-copy message construction.
The only solution I could come up with is to provide an allocator which incremented the pointer sizeof(int) before returning, then when the time comes to write the message decrement the pointer passed by sizeof(int). Of course this has the inherent flaw that any buffer to it that weren't allocated with the special incrementing constructor will cause... shall we say erratic results? It's just nasty...
A buffer should be a buffer. You shouldn't force programmers to cram things into the beginning of an arbitrary sized buffer.
IIRC, Xfree runs rootless on Mac OS X.
Forgive me if someone's already mentioned this, but I believe the fellow this person was responding to was talking about XFree running suid. This person appears to be confusing that to running without a root window.
I know you can use shared memory for data sharing in XFree but you still need the sockets or some other equally "selectable" IPC mechanism. The reason? Well most applications INCLUDING Gtk+ use a select()/poll() call to wait on the socket descriptor from the X server.
I believe the term you're looking for is "synchronous multiplexing." Check my forums for my rant about this.
My ideal solution: Using kqueues to multiplex Mach message queues. This may be possible on Darwin soon.
If properly implemented, kqueues provide near constant time synchronous multiplexing.
I was never advocating the use of ONLY shared memory. Obviously you need some means of message passing to coordinate the use of shared memory.
In fact, if you read my post I was advocating (for non-Mach platforms) the use of sockets in conjunction with shared memory.
Have you tried Local Domain sockets? Or perhaps implementing a stateful protocol over the connectionless IPC?
What, you think I was benchmarking against TCP sockets? Of course I was benchmarking against Unix domain sockets, and saw their performance to be 10%-50% better than Unix domain sockets, depending on the platform.
As to implementing any sort of protocol to remedy the connectionless nature of SysV message queues, I'd say this is a waste of time.
Eh? Did you try IPC_STATing the message queue and obtaining the pid of the last message (msg_lrpid)?
*COUGH*HACK*COUGH* I'd say a better solution would be to use a more thought out message passing mechanism such as Mach messaging.
The API offers quite a bit more flexability than sockets as well e.g. message priorities/types, persistence, etc. The Also, the atrocious API easily (and should be) be wrapped up into the equivalent of Xlib so the client would have no knowledge of the underlying IPC methods.
The problem arises precisely when you attempt to abstract SysV message queues. The queues expect the data buffer to be preceeded by a message type identifier. That means a great deal of nasty hacks to provide an abstract interface for zero-copy message construction.
The only solution I could come up with is to provide an allocator which incremented the pointer sizeof(int) before returning, then when the time comes to write the message decrement the pointer passed by sizeof(int). Of course this has the inherent flaw that any buffer to it that weren't allocated with the special incrementing constructor will cause... shall we say erratic results? It's just nasty...
A buffer should be a buffer. You shouldn't force programmers to cram things into the beginning of an arbitrary sized buffer.
IIRC, Xfree runs rootless on Mac OS X.
Forgive me if someone's already mentioned this, but I believe the fellow this person was responding to was talking about XFree running suid. This person appears to be confusing that to running without a root window.
I know you can use shared memory for data sharing in XFree but you still need the sockets or some other equally "selectable" IPC mechanism. The reason? Well most applications INCLUDING Gtk+ use a select()/poll() call to wait on the socket descriptor from the X server.
I believe the term you're looking for is "synchronous multiplexing." Check my forums for my rant about this.
My ideal solution: Using kqueues to multiplex Mach message queues. This may be possible on Darwin soon.
If properly implemented, kqueues provide near constant time synchronous multiplexing.
I was never advocating the use of ONLY shared memory. Obviously you need some means of message passing to coordinate the use of shared memory.
In fact, if you read my post I was advocating (for non-Mach platforms) the use of sockets in conjunction with shared memory.