You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by "Marvin Humphrey (JIRA)" <ji...@apache.org> on 2009/12/30 04:29:29 UTC

[jira] Commented: (LUCY-90) Stateless VTables

    [ 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.