In article <401081A1.E4C34F00 at alcyone.com>,
Erik Max Francis wrote:
Gary Robinson wrote:
I've recently had a couple of cases of needing exactly what it
having to kluge around the fact that it's not there. It's a great
If there anywhere else I should be expressing my opinion on this, let
Seems quite reasonable to me. The only issue I'd take with it is the
choice of Min and Max for the names of the singletons; they're a little
too close to the functions min and max, which obviously they're both
likely to be used with. I would suggest something a little more verbose
such as Minimum and Maximum, or if you want to get silly, Infimum and
I suppose you could special-case min() and max() to return the
appropriate singletons if called with no arguments.
There's something very nice about that. There's also something very
ugly about it. I'm having a hard time deciding which is stronger :-)
From http Fri Jan 23 06:06:32 2004
From: http (Paul Rubin)
Date: 22 Jan 2004 21:06:32 -0800
Subject: cgi concurrency approaches?
I'm wondering if folks here have favorite lightweight ways of dealing
with concurrency in cgi's. Take a simple case:
You want to write a cgi that implements a simple counter. The first
time it's called, it prints "1". The next time, "2", etc. The naive
implementation looks something like:
fd = open("counter.num", "rw")
n = int(fd.read())
print "Content-type: text/html\n\n"
but of course there's the obvious race condition if two people hit the
cgi at the same time.
Fancier solutions include running an transactional database in another
process and connecting to it, setting up a daemon that remembers the
counter value in memory and serializes access through a socket that
the cgi opens, using a file-system specific hack like linking to
counter file to lock it, having a timeout/retry if the counter is
locked, with a possible hangup if a lock file gets left around by
accident, etc. Each is a big pain in the neck.
Anyone have some simpler approaches?