Anders, You are right. These events are \"a global scratch pad\". If you look in the BrDetectorMonitor constructor, you will see that there is a static variable fgMonitorEvent which is creatd by the first monitor created and seen across all monitors. This is eventually set to fMonitorEvent, but the end result is that is what they do. I think that given this, marking the values with the event number will not add anything although I want to give it more thought. What I will do to help protect is to return a Bool_t when getting variables from other monitors. This return value will indicate whether or not it has been set. It does not solve the problem of order, but gives a monitor a means to know if the variable from the other monitor he wants to use has in fact been set. Adding this to the raw event would not solve the problem of order. It would just be another way to accomplish the same thing. This event I invented, in fact, inherits from BrEvent, but has some special features to make it \"easy to use\" for monitoring purposes. I elected against adding to the event, because I didn\'t want to mess with the input raw event. It would also be somewhat more cumbersome although a bit more efficient. Quoting Anders Holm <aholm@alf.nbi.dk>: > Hej Kris > > On Thu, 27 Jul 2000, Kris Hagel wrote: > > ... > > > > As far as the dangerous path, if there is a less > > dangerous path I did not think about, I would like to be > > made aware of it. This one has the strong benefit of > > being easy to use and that as much as anything drove the > > design. This is one that physicists will be using and I > > didn\\\'t want to build into the design something that > > needed alot of tinkering to be useful. > > > > Anyway, I am open as usual to any suggestions once > > people have had a chance to look at it. > > > > Kris > > As I understand you want variables calculated by one module to used in one > or more modules that are executed later. I worry about the execution > order and that supplyer code for evaluation might be conditional causing > values from som previous event to be used by the consumer modules. > > I suggested marking the values with the event number. The supplyer > might also just pass the variables along with the event and the mentioned > problems vould be solved. But then comes up the new problem of removeing > the variables from the event before it is written to where it has to go. > > You could also invent a global scratch pad with name-value pairs and have > the scratch pad erased at the beginning of a new event. But may be this > is exactly what you did. > > Anders > > ========================================================= > Anders Holm email: aholm@nbi.dk > Niels Bohr institute phone: (45) 35 32 52 13 > University of Copenhagen fax: (45) 35 32 50 16 > Blegdamsvej 17 > DK-2100 Copenhagen > Denmark > ======================================================== >
This archive was generated by hypermail 2b29 : Fri Jul 28 2000 - 08:47:36 EDT