I'm not sure this would be any faster. The time (and complexity) involved in communicating with another running process would probably be greater than just re-reading the files. In any case, the external process would have to be very efficient to handle the many simultaneous connections it would receive from a server under load. A database server would probably do this better than anything I could create.
Try this analogy: suppose spamdyke is a person who needs to make notes from a poster on the wall. The current version works by asking each person to read the poster and write down his own notes. Everyone can see the poster at the same time, so this works pretty well. Writing the notes takes a little time but because everyone's working separately, there's no waiting, even when lots of people show up. Using an external process (or a database) is like allowing only one person to see the poster. He makes notes, then reads them (in a whisper) to each person who needs them. Because he can't speak loudly, only one person at a time can listen. Because he's reading the notes, the people must still write them down. He's good at carrying on multiple conversations, so he can whisper a few words to one person, a few words to another person, etc, but he has limits. The speaking takes time and the writing takes time. If the crowd gets too big, eventually some people will have to wait in line. If the man with the notes leaves (or crashes), no one else can read the poster and everyone will be stuck. Using a parent process (a daemon that replaces tcpserver) is like making one set of notes, then making a photocopy for each person who needs them. It's very, very fast and there's no waiting. The copies are made as the people appear. I'm not sure if that helps but it's the best analogy I could think of. -- Sam Clippinger Paulo Henrique wrote: > I thought about using only one daemon that he would function as a > porter of configurations, keeping tcpserver. The processes of spamdyke > would have to consult this daemon and would receive the answers from > it. > > 2007/9/20, Sam Clippinger <[EMAIL PROTECTED]>: >> Unfortunately that's not really possible here because spamdyke is not a >> daemon -- a new copy of spamdyke is started (by tcpserver or xinetd) for >> each incoming connection. When each new copy is started, it must start >> from scratch to read and parse its configuration. >> >> I'd like to change that in a future version, so spamdyke will listen for >> the incoming connections instead of tcpserver. If that happens, the >> daemon can load and parse a large configuration file once. Then when it >> starts child processes, it can pass the parsed data to its children at >> zero cost. A bunch of other cool features become possible at that point. >> >> Unfortunately, I still need to come up with an elegant solution to this >> problem because not everyone will want to replace tcpserver with >> spamdyke. The configuration system will still need to function >> efficiently for those users. >> >> -- Sam Clippinger >> >> BC wrote: >>> On 9/20/2007 [EMAIL PROTECTED] wrote: >>>> The disk access is very slow in compared with memory (ram) access. >>>> >>>> In the file of options per user, there is only users with specific >>>> options, the default option is only 1 line where the admin can >>>> manipulate default actions. >>>> I'm not programmer, but believe to look for lines in file with 10000 >>>> lines not much slow...this file there's on memory previous load on >>>> startup and contain only specific options the users, not all users. >>>> >>>> I ask for excuses for the bad English, google helped me. >>>> >>> Your English is fine and I just love the way you folks discuss with Sam >>> the intricacies of how to solve a problem in the most efficient manner >>> possible. I've wondered too, if it is possible to load a config file >>> into memory once and then have it reread by each child process that is >>> invoked. Not sure how to do that in the programming environment being >>> used. (I'm not a programmer.) >>> >>> As a slight aside, Sam's posting of previous versions together with the >>> changelogs represents a splendid way to learn quite a bit about C >>> programming, streamlining and optimizing code. >>> >>> Bravo. >>> >>> Bucky >>> >>> _______________________________________________ >>> spamdyke-users mailing list >>> spamdyke-users@spamdyke.org >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> _______________________________________________ >> spamdyke-users mailing list >> spamdyke-users@spamdyke.org >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> > > _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
