Storing cgi data in stacks

[Alex Rice]

On Feb 18, 2004, at 7:07 AM, Richard MacLemale wrote:

> What would happen if you had two cgi scripts both
> writing to the same stack at the EXACT (within a thousandth of a 
> second)
> same time?  I'm thinking that while one script is writing to it, the 
> other
> script would not have write access, but I'm running OS X Server, so 
> maybe
> I'm wrong?

I would not assume it's safe. The OS does nothing to make it safe. MC's 
implementation language, C/C++, does nothing to make it safe. There is 
a C system call flock(), but the Runrev/Mc engine does not appear to 
have the flock() symbol so I assume that it does not call it anywhere.

This is a guess but: MC engine probably does an atomic write where a 
temp file is written, then the file is copied into place. That's safer 
because if the write fails, the last version of the file still exists.

You would have to use transcript to write an interface to flock() or 
use temp files as locking semaphores like Brian Yennie's example, but 
it can get messy- especially if processes die or get killed off then 
you have to figure out if a lock file is valid or leftover. Some CGI 
environments will kill off CGI scripts if they run for too long or use 
too much resources, for example. That could make the temp lock file 
method less reliable.

This is where multi-user SQL database can excel, and are widely used: 
they can interleave simultaneous insert/update commands. Incidentally, 
this is an area (fast inserts) that MySQL has historically been faster 
than other databases, although that may not be the case any more.

> The stuff I'm looking at is for small group use - not something
> that's going to be hit a kabillion times from the web.

If speed is not super-important, you could use shell() to find out if 
the data stack is opened by another process and if so, wait for a few 
ticks? I think you could use the fstat command for that. But not sure 
about which options to pass fstat.

--
Alex Rice | Mindlube Software | http://mindlube.com