>From: "Warmke, Doug" <doug_warmke@mentor.com> >b) Needless complexity. A deferred assertion can be placed > in a fork/join_none, and then a "disable fork" can be > called to kill any pending assertion reports when desired. This would not happen without some special rule being added to specify it. Currently "disable fork" does not disable any subprocesses of a thread except those created by a fork. The simplest rule would be that deferred assertions are treated like forked subprocesses by "disable fork". With that rule, there would be no need to put the assertion into a fork/join_none. > I like this approach better than explicit flushing, > since you have full addressability to any assertion > in your process. There is little chance of making a > mistake and disabling unintended assertions. I don't see how this gives full addressability, since a "disable fork" does not provide addressability. It disables all forked subprocesses of a process and all their children. I can imagine a convoluted scheme with nested fork/join_none and a wrapper process whose job is to kill its children on request, but I don't think it is practical. I doubt this is what you had in mind. So I don't really see any advantage in addressability. It does avoid adding a new construct, but with a reduction in addressability because of the inability to separately disable forks and deferred assertions. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Oct 23 17:28:46 2007
This archive was generated by hypermail 2.1.8 : Tue Oct 23 2007 - 17:29:07 PDT