This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: array sorting checked in


Hi -

hunt wrote:
> > OK.  It seems to me that the most straightforward way to expose this
> > in the language would be as a modifier for the "foreach" statement,
> > [...]
> > A related modifier could serve as an iteration count limiter [...]
> 
> That seems to add unnecessary complexity to the language. I understand
> you are focusing on the locking issues but there must be a better
> solution.

It's not just locking (i.e., correctness in the face of concurrency).
An array sorting operation has no script-visible effects other than
the order in which foreach() index tuples are processed.  It thus
makes sense to consider one as a preprocessing stage for the other.
(The runtime's provision of combined iterate/print functions is
independent of this point.)


> [...]
> > Adding a plain "sort <array>" operation would be of only limited
> > applicability, considering the possibility of concurrent/subsequent
> > modifications, invalidating the sorted property.  
> 
> > foreach should holds
> > a lock (but see bug #1275) on the array during iteration, which if
> > finagled properly, would protect the sorted property for the duration
> > of iteration.
> 
> This seems a poor excuse. Lets keep our language as simple as possible.
> [...]

It is an explanation, not an excuse.  Keeping the language simple is
not well served by your proposed introduction of two new constructs,
whose implications are somewhat beyond the small amount of extra
mechanism that foreach-sorted entails.


- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]