incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <>
Subject [jira] Resolved: (LUCY-90) Stateless VTables
Date Tue, 29 Dec 2009 07:04:29 GMT


Marvin Humphrey resolved LUCY-90.

    Resolution: Fixed

Committed as r894319.

> Stateless VTables
> -----------------
>                 Key: LUCY-90
>                 URL:
>             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:

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

View raw message