Windows-like registry for Linux?

[Steven W. Orr]

On Tuesday, Feb 14th 2006 at 15:18 -0500, quoth Jerry Feldman:

=>On Tuesday 14 February 2006 2:46 pm, Steven W. Orr wrote:
=>> Jerry, I'll disagree with you on this one. Use of System V ipc is highly
=>> deprecated. I did a big project back in '90 that was a heavy user of
=>> semaphores and msgqueues. It was the right thing to do back then but
=>> today it's dead wrong. Today, if you are writing interprocess
=>> communication within one machine, you should look at the socketpair call.
=>> (Under SVR4 we used something called STREAMS pipes which provided
=>> similiar
=>> functionality.) The idea is to write one process to be the keeper of the
=>> holy data and to make him a server process that people can connect to
=>> using socketpair. It's sort of like a pipe that is allowed to be used to
=>> connect two unrelated processes. One of the things about ipcs is the
=>> error recovery needed to ensure they work properly. e.g., I have a msgq
=>> that has a limit of X nr of messages. What are the clients supposed to do
=>> if the enqueue fails? All of those class of problems go away if you use
=>> the correct architecture.
=>I have no qualms on this, but I also don't think that socketpair(2) is the 
=>answer per se., but the issue is more in the detail. If all that is needed 
=>is a common lookup table and a place to register a service, then possibly 
=>mmap(2) in combination with socketpair(2) and some of the other socket 
=>oriented calls would work fine. Possibly even fifos.  I'm advocating more 
=>of an in-memory approach rather than a database approach. 

Right. socketpair is not the answer. It's just part of a proper 
architectural approach. What I'm suggesting is that a single server gets 
designed to access the data, maybe even using mmap or whatever else you 
want to use. Then that server would accept connections from arbitrary 
clients. The clients connect using the socketpair trick and then a 
mini-language would be used to tell the server what it is that the client 
wants. That way access is confined to one process (the server), runtime 
overhead is confined to one process (the server), and the client ends up 
stoopider and simpler. 

Fifos are almost to be avoided more than SVR4 ipcs just because of how 
problematic the rendezvous is. You almost need a socketpair based server 
to tell the two processes which fifo to use. ;-)

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net