----- Original Message -----
> 1) You are uncomfortable with the notion that calling a function pointer
> from a different context will crash or cause memory corruption.
yep.
>
> - I do not believe this is a problem in practice. When I said that my
> implementation does not suffer this problem I incorrectly implied that the
> code to prevent this is NV-specific; in fact is it derived from the DDK
and
> I fully expect most (all?) other implementations can handle this in the
> same manner. In fact we can mandate it - calling a function pointer
> returned by glGetProcAddress when a different context is bound has
> undefined results but must not crash or do anything nasty. We cannot
> require it to set an error because the same pointer may be returned by
> different contexts in a given implementation. Thus your worst case
> scenario, data corrpution, can not occur. This is really simple to
> implement, and like I said, already is in most windows drivers.
This is all good stuff. This is the sort of thing an application expects of
a driver. But you have confused me, because I thought your object to the
getProc being context independent was driver overhead and complexity of
implementation. It sound to me like the context dependant implementation
you've got has all the complexity, overhead, et. al. that you are concerned
about a context independent version imposing. It detects and validates the
context, and even sets (or could set) an error based on the validation. It
only differs from a context independent version in two ways
(1) It is less convenient. One must retrieve a proc for each context in
order to use an extension in that context. Since, as we have already
agreed, the getProc return value cannot be used to verify the exsistance of
an extension -- there is no value added, and no additional information
provided to the application by this step. It is simply an extra per-context
step imposed by a context-dependant specification.
(2) It is less capable. The implementation you describe does everything a
context independant implementation requires (potentially more since you have
a dispatch step AND a validation step), but simply fails to go the last cm
and invoke the proper extension proc registered by the driver for the
current context. The context dependant design seems to require the driver
implementer to do all of the work relative to a context independent one, but
not gain all the end-user functionality and convenience.
Beyond that I'm at a loss to see any differences at all between the two.
Given that, why would one prefer the context-dependent version? (excepting
of course compatibility with wgl)
On a personal note:
> Does this make me callous? Perhaps.
> I've certainly been called worse.
You're right I did say your attitude was callous. That's not to say YOU are
callous (which I didn't say), but it is borderline name-calling.
Sorry.
What I should have said is the design criteria you had outlined "a bug is a
bug, if it crashes... tough" is callous. Clearly from your thoughtful posts
and how you've described your drivers you don't in fact just say "tough" to
your user base -- I guess I was trying to point out the cognative dissonance
of your proposed design criteria and your actual implementation approach.
(and utterly failing in the attempt)
Best Regards,
John
