atomic get-then-delete command

[Mathias Herberts]

Hi Scott,

it seems to me that a real consume command would need memcached to
have the ability to store different objects under the same key, that
is manage a real queue. Right now only one object can be stored under
a single key and that is one short message queue!

Or maybe use two additional keys, one for a produced counter, the
other for a consumed counter, and add the counter value to the name of
the queue to get a key for the next message to retrieve.

With a little tweaking I guess memcached could be turned into a poor man's MOM.

Mathias.

On 4/20/05, scott moody <conspyre at gmail.com> wrote:
> Hello,
> 
> I'm completely new to memcached (and I'm happy to report that I've had
> no problems getting everything up-and-running).  I know protocols
> aren't something one extends on a whim, but I was wondering if the
> addition of an atomic 'get-then-delete' command has ever been bandied
> about by anyone here.  I would use such a command (which I refer to as
> a "consume" command) for memcached-based queues in order to implement
> non-persistent Linda/tuplespace/distributed computing patterns.
> 
> My question is:  Is such a command a bad idea for any reason?  I ask
> because I cloned and then frankensteined the handler for the "get"
> command in memcached.c to create such a beast and it seems to be
> working okay thus far -- but I haven't programmed in C in nearly a
> dozen years and don't know the memcache code, so I'm certain that it's
> not a commercial-grade mod. However, it would seem to me that, because
> of the singled-threaded nature of memcached, it shouldn't a risky
> proposition.  Am I wrong?
> 
> Apologies for adding even more mail to your inbox,
> 
>    Scott
>