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