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/27 20:19:29 UTC

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

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


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.


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

Posted by "Marvin Humphrey (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/LUCY-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marvin Humphrey updated LUCY-90:
--------------------------------

    Attachment: stateless_vtables.diff

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


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

Posted by "Marvin Humphrey (JIRA)" <ji...@apache.org>.
    [ 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.


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

Posted by "Marvin Humphrey (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/LUCY-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marvin Humphrey resolved LUCY-90.
---------------------------------

    Resolution: Fixed

Committed as r894319.

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