Subject: Re: [sv-cc] Updated extern/exports proposal
From: Stickley, John (john_stickley@mentorg.com)
Date: Wed Mar 12 2003 - 14:54:57 PST
Slight correction to this. You don't really need the cname
argument on svGetUserData(). In fact, you really don't want
it as it would cause possible hashing overhead on a call
used frequently during run-time.
When calling svGetUserData() from inside a call to an extern
function call, the infrastructure will know not only the
current context but the current function being called.
So really, it should know how to return the correct
user data for that function.
It seems you would only need it on the svPutUserData()
call which would typically be called only at init time.
One thing we might consider doing for simpler applications
is that if the cname passed to svPutUserData is NULL then
it would revert back to one user data per SV module instance
as we have it now. Only when a cname is supplied would it
then associate with a specific function of a specific module
instance.
How does this sound ?
-- johnS
John Stickley wrote:
> Doug,
>
> Warmke, Doug wrote:
>
>>
>> 2) The purvue of the user data should be per-function,
>> rather than per-scope. Otherwise it will be impossible
>> to mix completely independent external context functions
>> within the same module scope.
>
>
> johnS:
> This is the solution I had in mind when we discussed
> this issue in today's meeting. You should have spoken up !
> Anyway, it was decided to discuss by e-mail.
>
> To clarify what I think you are saying, we need
> svPut/GetUserData() to take a second argument
> in addition to the svScope, namely, the function name
> - as a string I guess. Does that make sense ?
>
> Something like this:
>
> void* svGetUserData(const svScope, const char *cname );
>
> void svPutUserData( const svScope, const char *cname, void * );
>
> where cname is the 'cname' in one of the extern declarations
> given in the scope (or the fname if aliasing is not used).
>
> Is this what you were thinking Doug ? It seems to be
> to be a fairly simple solution.
>
>>
>> This is a trade-off and may be an opinion-call.
>>
>> As you have defined it (user data shared by all extern
>> functions in the scope) it is convenient for implementors
>> of sets of related external functions. However, if there
>> are multiple independent external context functions declared in
>> the same module scope, they couldn't
>> co-exist. (Similar to having multiple UNIX signal
>> handlers all on SIGINT, but *no* handler-chaining
>> mechanism defined so that they can co-exist).
>>
> > [...]
>
> -- johnS
> __
> ______ | \
> ______________________/ \__ / \
> \ H Dome ___/ |
> John Stickley E | a __ ___/ / \____
> Principal Engineer l | l | \ /
> Verification Solutions Group | f | \/ ____
> Mentor Graphics Corp. - MED C \ -- / /
> 17 E. Cedar Place a \ __/ / /
> Ramsey, NJ 07446 p | / ___/
> | / /
> mailto:John_Stickley@mentor.com \ /
> Phone: (201)818-2585 \ /
> ---------
>
--This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ ______ | \ ______________________/ \__ / \ \ H Dome ___/ | John Stickley E | a __ ___/ / \____ Principal Engineer l | l | \ / Verification Solutions Group | f | \/ ____ Mentor Graphics Corp. - MED C \ -- / / 17 E. Cedar Place a \ __/ / / Ramsey, NJ 07446 p | / ___/ | / / mailto:John_Stickley@mentor.com \ / Phone: (201)818-2585 \ / ---------
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 14:57:20 PST