On Tue, Sep 05, 2000 at 10:57:30PM -0400, Chaim Frenkel wrote:
> >>>>> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
> >> Now, "all" that needs to be taken care of, is make sure that the final
> >> assignment from the localized and changed variables to their
> >> outer-scoped counterparts happens in *one step*, i.e. no task switching
> >> while this is going on.
>
> JH> Well, that can't be done. (I assume that by 'task switching' you mean
> JH> here 'thread switching') Or, if it can, it *shouldn't* be done.
> JH> Threads run on their own until they yield, they decide to synchronize
> JH> and/or join, or they exit. Note the "they decide".
>
> I think what he _really_ should have said, is a lock is taken on all
> relevant structures and an update is performed.
Who takes the lock? Different threads may be holding the relevant
structures, which leads us into...
> This gets into deadlocking issues, extra locks to hold the variables until
...yes, deadlocking. "You give that SV* to me, right now!" "Not before
you give me that malloced string buffer!" "I don't care what you two
are arguing about, just fork over your code references to me...."
> the commit. Or perhaps we get into versioning of variables and then we
> buy problems of how to do rollbacks and retryies.
>
> I don't think we can do this immediately. Can you come up with the right
> API and/or hooks that are needed so that it might be retrofited?
I think language magic helping to do the user level data locking is
a dead-in-the-water idea. For some very simply problems it may work,
but that support need not be implemented by internals.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
