> -----Original Message----- > From: Bakken, Luke [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 06, 2003 4:47 PM > To: Michael Weber; [EMAIL PROTECTED] > Subject: RE: Handling race conditions > > > It sounds like you need two things: > > 1. A faster way of storing "seen" IPs. > 2. A lock mechanism to keep perl processes queued up waiting to write > new iptables entries.
Sorry to harp on this, but a lock file will not work in every case. Shared memory will not work. Every implementation of this results in code that has to: 1) check for lock 2) lock As someone suggested, this is not just a multi-server design issue, it is a multi-tasking OS issue. You just cannot control the situation where 2 processes are running almost together, and they both arrive at the code to check for a lock at the same time. 1 will get in first, but the other will also see no lock before the first has a chance to create the lock. Client-server through a socket is 1 easy way in perl to make sure that no other program can get "in between" the call to check for a lock and the call to create the lock. My original point was simply that in other languages this may be a difficult thing to do, but it is not so hard in perl. Of course, you could go assembly and ask the OS to lock your process in until you finish, but my use of perl is to write platform independent as much as possible, so I wouldn't do that. Ok, I'm done trying to convince you, I have been there, done that. -Mark -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
