From 0e5441d8161042493fcfdacaeed2a770f1f7285c Mon Sep 17 00:00:00 2001 From: antirez Date: Thu, 22 Jul 2010 13:08:02 +0200 Subject: don't use object sharing inside I/O threads, as a fix for a well known instability of VM introduced with the new object sharing code --- src/object.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'src/object.c') diff --git a/src/object.c b/src/object.c index 772637ce0..25567e2ac 100644 --- a/src/object.c +++ b/src/object.c @@ -213,8 +213,15 @@ robj *tryObjectEncoding(robj *o) { /* Check if we can represent this string as a long integer */ if (isStringRepresentableAsLong(s,&value) == REDIS_ERR) return o; - /* Ok, this object can be encoded */ - if (value >= 0 && value < REDIS_SHARED_INTEGERS) { + /* Ok, this object can be encoded... + * + * Can I use a shared object? Only if the object is inside a given + * range and if this is the main thread, sinc when VM is enabled we + * have the constraint that I/O thread should only handle non-shared + * objects, in order to avoid race conditions (we don't have per-object + * locking). */ + if (value >= 0 && value < REDIS_SHARED_INTEGERS && + pthread_equal(pthread_self(),server.mainthread)) { decrRefCount(o); incrRefCount(shared.integers[value]); return shared.integers[value]; -- cgit v1.2.1