Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Message-ID: <1219574970.1262143769421.JavaMail.jira@brutus.apache.org>
Date: Wed, 30 Dec 2009 03:29:29 +0000 (UTC)
From: "Marvin Humphrey (JIRA)" <jira@apache.org>
To: lucy-dev@lucene.apache.org
Subject: [jira] Commented: (LUCY-90) Stateless VTables
In-Reply-To: <322896969.1261941569646.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCY-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795227#action_12795227 ] 

Marvin Humphrey commented on LUCY-90:
-------------------------------------

Test file committed as r894538 -- it was missed on the earlier commit.

> Stateless VTables
> -----------------
>
>                 Key: LUCY-90
>                 URL: https://issues.apache.org/jira/browse/LUCY-90
>             Project: Lucy
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Marvin Humphrey
>            Assignee: Marvin Humphrey
>         Attachments: stateless_vtables.diff
>
>
> Making VTables immortal is step one towards basic thread-safety for Lucy as a
> library.  This patch removes reference counting from VTables, and also
> ensures that once added to the VTable_registry they are never removed.
> We would like to make VTables completely stateless, and this patch achieves
> that for everything except the VTable's cached host object.  In Perl's case,
> it is impossible to stop the host from manipulating the cached host object's
> SvREFCNT; other hosts may have similar constraints.  
> It is assumed that the host knows how to serialize access to its own objects
> (which we achieve in Perl by calling "SvSHARE(vtable->ref.host_obj)").  For
> the rest of Lucy, we simply deny access to the host object by making
> VTable_Inc_RefCount() and VTable_Dec_RefCount() no-ops, and by having
> VTable_Get_RefCount() always return 1 regardless of the state of the host
> object.  
> With that refcounting trick in place, from the perspective of Lucy's innards,
> VTables are stateless.
> The VTable registration process is still racy -- it is not safe to create and
> register new VTable singletons from multiple threads -- but that is left for
> another patch.
> Mailing list discussion: http://markmail.org/message/eyjvfc72r653t76i

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.