On Tuesday 18 October 2005 15:22, Marty Kraimer wrote:
> I am concerned about how complex it will be to implement something
> like what Benjamin is proposing.
>
> The original proposal uses "block" to mean no further record
> processing until this link and all previous links complete.
> Bemjamin's proposal uses "after" to mean the this link (or something
> more generic) should not be processed until a list of other links (or
> something more generic) completes.
> [...]
> Maintaining after lists sounds complex to implement.
Ok, let me sketch a possible implementation. Let X be some field of a
record R that can be 'processed' and might send some notification after
completion (for example a link field).
Let Y be another field of R that denotes some action to be done during
processing of the record (for example another link field; or a field
denoting record process completion). For each such field the record
contains an array or a list of field identifiers (pointers or indices)
on whose completion execution of step Y depends (specified by its
attribute 'after' (or whatever it will be called in the end)).
As soon as the record undertakes to execute the processing step denoted
by Y, it 'blocks'. Well, what it really does is return control to the
core library, indicating the desired step (for instance by setting a
special field). The core now checks if all conditions are fulfilled
(i.e. all Xs on which Y needs to wait have completed), and in this case
control is returned immediately to the record. Otherwise the record is
put on a wait list. Whenever some X completes, it calls a core routine
that sets its completion flag and then looks up(*) the list belonging
to field Y of record R to check if now all conditions are fulfilled. If
yes it wakes up some task that will proceed processing the record.
Many variations of this scheme are possible, of course. For instance,
bitmasks could be used instead of arrays or lists to store the
completion flags that a record waits for. All in all, it looks to me as
if the proposal could be implemented without undue overhead.
> Is it more
> intuitive for the database developer? Not clear to me.
Well, the approach I proposed is obviously more declarative in nature
which some may find less intuitive. OTOH, the semantics is very simple
and easy to understand. It is also explicit and unambigous about all
processing/completion dependencies. I would think that this will become
an advantage in the long run i.e. when it comes to maintainability; but
again, others may have a different opinion.
Cheers,
Ben
(*) This lookup is cheap, it is merely a double indirection. The check
itself is linear in the number of completions to be waited for.
- References:
- [Fwd: Re: Link arrays / syntax] Marty Kraimer
- Re: [Fwd: Re: Link arrays / syntax] Benjamin Franksen
- Re: [Fwd: Re: Link arrays / syntax] Marty Kraimer
- Navigate by Date:
- Prev:
Re: alarm/severity Andrew Johnson
- Next:
Requirements? Re: alarm/severity Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Link arrays / syntax Andrew Johnson
- Next:
Re: PP and MS Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|