Re: [Accellera:itc] IM324: Support one-time callbacks and multiple callbacks

Hi John,

> Thanks for the writeup of this.

You're welcome :-)

> johnS:
> Why is the handle not simply a 'void *' ? The implementation defined
> type can be simply concealed in the implementation. An
> opaque void * pointer should be sufficient at the application
> level.
>
> Also, void * is what we now use for pipe handles which have
> similar semantics so it would be more consistent to
> use this for callback handles as well.

I wanted to make the actual type that the typedef is mapped to be up
to the implementation. All the user will need to worry about is the
scemi_pipe_notify_handle type name. What it is actually typedef'ed
to is not relevant to the application.

But I am not terribly opposed to mandating that it be void * for
consistency with the other handle type. One benefit is that it makes
the code snippets in the standard valid C/C++ . . .

> johnS:
> This 'N' argument is still a little goofy to me.
>
> We're overloading persistence vs. non-persistence with
> a callback threshold.
>
> I suggest that we just have 0 be persistent and 1 be non-persistent
> for now. If we need more complex usage down the road we can
> expand this.

I took that straight out of Amy's proposal. Amy can explain the benefits
of the N argument.

> johnS:
> I suggest we do not do error handling with a return argument
> for this call alone.
>
> This is inconsistent with what we do for all the other calls
> which is to rely on the SCE-MI error handling facility.
>
> I think we can make the return type 'void' in this case and
> defer errors to the error handling facility.

OK, I went back and forth on this, and decided to punt the error handling
to the caller. With the current SCE-MI error handling facility, error
handling is non-local as it is done by a callback . . .

Thanks,
Per

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