Re: Re: trellis.Set.discard

I have changed TodoValue to allow only the original rule to access it,
which means there's no need for saved savepoint. This didn't break any
of my code and helped me find two cases of misuse for todo / future.
I'm pretty sure that futures as they are implemented are completely
invalid, aside from the rollback issue, changed(self) is only called
on first access and it all just doesn't fit the dependency tracking
model.

For things like Pipe to work with multiple inputs, a similar cell with
multiple futures  and merge is needed, which I'm working on right now.

On Sun, Oct 12, 2008 at 10:06, Sergey Schetinin <[email protected]> wrote:
> Just to make it more clear, what I mean is that
> Component.__class_call__ would set up a separate transaction to create
> and initialize the cells. There also needs to be a way for cells to
> mark themselves as being involved in some transaction, so that if
> during this initialization any of the cells already read or written in
> current transaction are changed in this additional transaction, this
> would be detected and result in exception. With this, some of existing
> code would become invalid, but rightly so, because some things should
> be prohibited during initialization. Also, a lot of changes required
> are needed to enable safe multithreaded use of Trellis.
>
> If we add the requirement that the same future value is only available
> to the rule that first created, it seems to me that the problem with
> one savepoint per transaction would go away.
>



-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter