CGI and DestroyStack property

[LiangTyan Fui]

On Apr 28, 2006, at 10:19 AM, Brian Yennie wrote:

>> It is rather crud to use PHP -> socket -> MC.
>> The MC socket port listening method is not robust enough, and may  
>> went deaf under some loads.
>
> I think Pierre would disagree. I would also - it's a whole lot more  
> likely to handle a big load than a CGI that loads the whole engine  
> with every request. There's nothing crud about it, it works quite  
> well.
>
>> You don't have to use PHP to handle the browser POST queries. We  
>> have pure MC CGI written to handle POST running for years without  
>> problem.
>>
>> Unless you need to MC running as daemon explicitly, I don't see  
>> the need of PHP here.
>
> That was the point of this thread... I think you missed the  
> requirements. The original poster already has a working CGI, but  
> wanted a daemon solution to easily solve read/write conflicts for  
> the stack.

Let me proposed a solution here, which works for us. We was trying to  
resolve a race condition on writing on a same file (not stack) by  
intensive CGI queries.

1. moved the files onto high I/O efficient RAM disk, or the shared  
memory at /dev/shm

2. implement a pseudo lock and unlock method, here is how:

# When you load stack, do this:
put false into stackOpenStatus
repeat 60 # retry for 1 minute
   if there is a stack myStackName then
     # try to rename it
     rename myStackName to (myStackName &".lock")
     if the result = "" then
       # manage to rename, no error, so the lock is on!
       open stack (myStackName &".lock")
       put true into stackOpenStatus
       exit repeat
     end if
   end if

   wait 1 second
end repeat
# remember to test the stackOpenStatus first before proceed.


# When you write stack, do this:
save stack (myStackName &".lock") # save to the lock one
rename (myStackName &".lock") to myStackName # make it available again

Hope this helps.

--