[lug] Fwd: Simple counter?

[Bear Giles]

My concern with the file locks is if it's on something like an NFS-mounted
or certain types of encrypted filesystems (that are built on top of NFS).
You wouldn't expect someone to do that but if it's a general library you
can't always make these assumptions.


On Sat, May 25, 2013 at 1:08 AM, Paul Condon <pecondon1 at gmail.com> wrote:

> On 05/24/2013 11:22 PM, Anthony Foiani wrote:
> > Paul Condon<pecondon1 at gmail.com>  writes:
> >
> >> I take [the existence of lockfile-progs] as proof that the issues
> >> involved in a "Simple Counter" have been considered by others before
> >> us, and that the full solution will be far from "simple" ;-)
> > Aye.
> >
> >> I suggest a system based on using email and a single mailing list server
> >> listening for requests for the 'next' number.
> This suggestion is supposed to be a (prototype|test bed), not the final,
> deployed, grand solution.
> > Now we're into "mortar as flyswatter" territory.  Possibly "tactical
> > nuke as flyswatter".
> >
> > No doubt that there are situations where this is exactly the correct
> > solution.  I can't say that it's the first one that springs to mind,
> > though, given the original problem description.
> >
> >> My belief is, further, that liblockfile is in the public domain and
> >> can be ported to any distribution to which it is not already ported,
> >> and that this list could be used as a test bed by reserving the
> >> subject line "test of simple counter" to identify incoming emails
> >> that are intended for the test. Or maybe set up an entirely separate
> >> list, but using the existing hardware.
> > And now you're so meta that I'm completely lost.  :)
> My thought is that, with the suggested test bed, one can emulate the
> behavior of any 'more simple' design and discover whether or not the
> modified design meets the requirements, as augmented by requirements
> discovered by having testers pound away on keyboards of the prototype.
> >  From my point of view, it seems clear that there is no one optimal way
> > to do it.  The "best way" will depend on the requirements of the given
> > use.  Everything from threads within the same process (for which
> > atomics is fine, maybe at the cost of a few instructions or a cache
> > line invalidation) all the way up to billions of internet hosts (where
> > the requirement for unique, sequential numbers is so great that it's
> > worth dozens of seconds and millions of cycles and possibly
> > non-trivial network bandwidth, let alone connectivity).
> >
> > And that's ok.  I've had enough issues with projects that are bogged
> > down due to "perfect is the enemy of good" impasses.
> >
> > Happy hacking,
> > t.
> >
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20130525/12cb893d/attachment.html>