Windows-like registry for Linux?

[Steven W. Orr]

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

=>On Tuesday 14 February 2006 1:24 pm, Michael ODonnell wrote:
=>> A cow-orker is tasked with implementing a lean-
=>> and-mean registry thingy that's maybe similar
=>> to the Windows registry, or maybe not.  The real
=>> goal is for multiple processes/threads to be able
=>> to perform attribute lookups cheaply and reliably
=>> and possibly VERY frequently (many thousands/sec)
=>> with updates possible but very infrequent.
=>Actually, a Windows style registry is a very bad thing as it not only 
=>represents a single point of failure that could render a system unusable, 
=>but also is a tool that is used by hackers. 
=>
=>In addition to a database, like Berkeley DB, I have seen message queues and 
=>shared memory, or more generally ipc(5). Much depends on whether you want 
=>to maintain the data between boots, but since Linux systems tend to stay up 
=>for many (hundreds of) days, it is sometimes cheaper to reinitialize on a 
=>boot. Additionally, you may want to consider the possibility that the 
=>system may use more than one computer. In any case, ipc(5) contains most of 
=>the tools you need (shared memory, semaphores, messages). Also look at 
=>mmap(2). With mmap(2) you can open a file that can be shared between 
=>processes. What you are doing in the case of a file is simply mapping that 
=>file into virtual memory. 
=>On the other hand, if you need a very fast database, Berkeley is probably 
=>one of the fastest and most reliable. On the downside of Berkeley, I was 
=>working on a driver's license system where we had a home-grown database. I 
=>was asked to check out Berkeley, and it failed on my benchmark with was a 
=>simulation of data from all the drivers license offices based on an average 
=>transaction rate, but that was 5 years ago. 

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.

-- 
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