| |||||||||||||
|
| |||||||||||||
Ghosts of Unix Past: a historic search for design patternsGhosts of Unix Past: a historic search for design patternsPosted Oct 27, 2010 17:49 UTC (Wed) by wahern (subscriber, #37304)In reply to: Ghosts of Unix Past: a historic search for design patterns by iabervon Parent article: Ghosts of Unix Past: a historical search for design patterns
The dialog box's API could just provide a socket descriptor. Reads are troublesome; you could allow atomic reads if the socket was a SOCK_DGRAM type, but only up to some limit (usually around 65535).
In Linux you could use an eventfd for signaling, and either fall back to the API for reading, or use a second descriptor (i.e. an unlinked tmp file to hold the contents).
It's all quite ugly, though, except eventfd can be an elegant solution for purely signaling purposes. And none of this is based on named objects, only anonymous descriptors. FUSE seems like overkill, though.
(Log in to post comments)
Ghosts of Unix Past: a historic search for design patterns Posted Oct 27, 2010 23:10 UTC (Wed) by jg (guest, #17537) [Link]
Fuse would be fine... Seems like the right idea to me. Sure beats the NFS X implementation, that most have mercifully forgotten was done at one point. I'd certainly like to be able to wander through my graphics system for lots of reasons.
Unfortunately, it didn't exist in 1984: there were 20 file descriptors total a process could use in that era.
|
|
||||||||||||