You feel victim to one of the classic blunders, the most famous of which is "Never get involved in a land war in Asia", but only slightly less well known is this: Never schedule two related cronjobs and hope they don't step on each other. Put them both in a script to run serially and schedule the script.
LOL -- actually, it's not something we wanted to do, but given the nature of the larger system (too many details to get into here), we couldn't avoid it, and launching serially wouldn't work either, unfortunately.
Well, it's wrong, but not in that way. Neither function closes the file handle, but they don't return it either, so nobody else can close it, so they "leak" file handles. But if you're not doing it that way, nevermind. :)
Ah, I misread your example functions as using (with-file-open) but you used plain old (open), so yes, you're right. Because the (with-file-open) macro handles file close seamlessly, it's become automatic for me to think in terms of that macro for *any* file access I want to do, rather than the simpler open/close functions.
That looks okay to my non-Lisp-expert eyes. I'd probably write it as a macro, but tastes (and requirements :) vary. Note that if FN raises a condition, with-file-lock will return NIL. Not necessarily an error, of course.
Yeah, the logic which invokes (with-file-lock) is conditioned to expect and react to NIL return values, which means something's gone wrong with the actual read/write action in the (apply fn args) statement. One thing I thought had the potential of being a problem is the case where the call to (lockfile) works, but the call to (unlockfile) fails: it would return the first time, but any *subsequent* calls on that same file would result in an endless loop. It hasn't happened yet in testing, but this is the kind of things where you want to be sure, so we'll be throwing the kitchen sink at it.
