RE: [sv-bc] Special E-mail vote due May 13 11:59pm PDT

I was thinking you still would be useful to use srandom() which requires
a handle to a process.

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Steven Sharp
> Sent: Tuesday, May 12, 2009 4:55 PM
> To: sv-bc@server.eda.org; matthew.r.maidment@intel.com
> Subject: Re: [sv-bc] Special E-mail vote due May 13 11:59pm PDT
> 
> 
> >SVDB 2691 _X_Yes   ___No
> >http://www.eda.org/svdb/view.php?id=2691
> 
> Though I am voting in favor of this, it has occurred to me that there
is
> a more elegant way to get this restriction: just specify that the
> self() method returns null or is an error if not invoked from an
initial,
> always or forked process.  Since there is no other way to get a handle
> to a process, this automatically prevents invoking any of the other
> methods on these.
> 
> This is also consistent with the LRM's description of a thread or
process,
> which does not include these other things (except maybe for continuous
> assignments).  If they aren't considered processes, you shouldn't be
able
> to get a process handle to one.
> 
> After you eliminate kill(), await(), suspend() and resume(), there
isn't
> much point in having a handle to these other things anyway.  It would
> only leave status(), and most of the descriptions of the process
status
> have to be extrapolated to apply to these other things.
> 
> But there isn't enough time for an alternate proposal, and this
proposal
> does solve the problem.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.