Re: Make eLauncherAuthor thread-safe [patch]

On 10 March 2010 14:10, Kevin Reid <[email protected]> wrote:
> On Mar 10, 2010, at 8:49, Thomas Leonard wrote:
>
>> There are three commits. The first adds a VatSeeder Java class, which
>> can be passed to Vat.seed and evaluates its twine in privileged scope.
>> This is needed because safeScope is not thread-safe, so it is never OK
>> to pass an E object here (as eLauncherAuthor does). It also changes
>> seedVatAuthor to use the new system:
>>
>>  http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/8240992d252cdf65311113a6fd910ad468c1e3c8
>
> Why not use seedVatAuthor rather than adding any Java code? It was our
> intent that seedVatAuthor is a sufficiently safe mechanism. Does it
> fail to be?

It's possible that it is thread-safe, but I'd be surprised. It's very
fragile. For example, it started:

        to run(vat :Vat, privSrc :String) :rcvr {
            return vat.seed(fn{
                def eParser := <elang:syntax.makeEParser>

If makeEParser was an emaker, this would certainly be unsafe
(ImportLoader isn't thread-safe for E code).
If it bound it using =~, it would be unsafe (the lazy slot used by the
__matchBind expansion isn't safe).
If it tried to verify the result with require(eParser != null) it
would be unsafe.
If the "auths" map returned by runeAuthor wasn't thread-safe, it would
be unsafe too.
etc

It seemed like verifying every line of code used for unsafe things was
harder than replacing it with a bit of Java.


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA