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
_______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
