> I got rid of clump (except for signals). Why do you need it for var
> watchers?
Well, as we saw, a single perl statement can be translated into a number of internal
accesses. But my intention to write a watcher is to get informed if, lets say, the
variable is modified. I want to get informed ONCE. Noone can determine which exact
operations will be performed on the watched variable - this may be done even by
third party code. Even if I could exactly know which code could be performed on the
variable, I would have to be a Perl kernel guru to predict all the exact accesses.
So, if I have a read watcher and its callback is called for any internal access,
this may be just what someone wishes, but in most cases a combination into a single
"meta event" (providing a counter?) would be more useful - it would simply flag that
SOMETHING happened.
This was my intention to remember "clumb".
Hm, on the other hand, while writing this a thought arrived: this special kind of
difficulties only occurs if I watch READ access, doesn't it? If I would have limited
the watcher to write accesses, only a single callback would have been performed. So
I assume most variable watchers will watch write access. So the problem could be
"solved" by documenting that it is EXTREMELY difficult to use READ var watchers,
that a user should expect MANY callback invokations which almost noone can predict,
and that he should check the events "got" attribute very carefully in such callbacks
to avoid multiple actions for the same event. (Of course, this is only a solution if
we can be sure that ALL perl statements which MODIFY a variable result in only ONE
internal write access. Am I right?)
> The implicit join does another read of the variable.
Ah, thanks for your research!
I assume the second implicit join() was optimized by the runtime engine? These
details illustrate how important it could be to combine accesses at request, I think
...
Jochen
