John,
Let me see if I can address your concerns. I'll attempt to summarize your
post:
1) You are uncomfortable with the notion that calling a function pointer
from a different context will crash or cause memory corruption.
- 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. (By the
way, to nitpick with your example, it is perfectly valid to call glIndex in
an RGB context and you can query the current value.)
2) You are concerned about obscure bugs that can result from calling the
function in the wrong context.
- There are many bugs which can (and do) occur when applications call the
wrong function at the wrong time; e.g. between a begin/end, when in display
list compile vs. immediate mode, when the wrong texture is bound, etc. I
am all for designing an interface which minimizes the developer's exposure
to this kind of bug, but I prefer to draw the line at burdening the
implementation to achieve this, especially when all Windows codes already
have to be aware of this restriction. Does this make me callous? Perhaps.
I've certainly been called worse.
Thanks,
-- Michael
At 08:44 PM 10/16/99 -0700, John M. Zulauf wrote:
>
>----- Original Message -----
>From: Michael I. Gold <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, October 15, 1999 10:34 AM
>Subject: Re: [oglbase-discuss] Updated GL_EXT_get_proc_address spec
>
>
>> This is not a problem in my implementation - the returned
>context-dependent
>> pointer is a routine which uses a per-thread dispatch table. If none of
>my
>> contexts are bound to the current thread, it will dispatch to a nop
>function.
>
>then in a way are you saying that the proc functions like the context
>independent proc would in this case? (grin)
>
>>
>> Even if this were not true, and memory corruption occurred - a bug is a
>bug
>> is a bug. I don't think we should design the interface to prevent buggy
>> programs from crashing.
>
>But one also should not design an interface such that it promotes minor
>errors to core dumps. Would you want a call to glIndex to crash an
>application if the current context is for an RGB window? This is exactly
>analogous -- the application making an OpenGL function call incorrectly in a
>context not supporting that capability. If we hadn't gotten the proc from
>getProc but from the header file and linked with it directly we wouldn't
>crash, right? Your attitude seems a trifle callous -- especially since in
>using a dispatch table you could as easily (and with no additional overhead)
>avoided the whole problem by implementing the getProc in a
>context-independent way. Its one thing when a program hands a driver a NULL
>pointer, or forgets an initialization step, this sort of thing is fairly
>obvious and easily tracked down as it will fail at the actual bug or at the
>first real graphics call.
>
>What we're talking here about is a data corruption bug which could lead to a
>crash very far removed from the actual erroneous call. These are among the
>hardest bugs for applications developers to find. I tracked a hard to find
>and reproduce a crash happening from within a windows dialogbox. The
>arguments to the dialog box were perfect, the callbacks flawless. The
>fault? Some NLS support settings in some obscure corner were being done
>incorrectly and thus apparently corrupting the window internal font handling
>or who knows what. This bug accounted for man-weeks (plural) of effort.
>It's one thing to slow good applications by always checking for NULL
>(nothing I'd advocate, except in a debug library...), clearly that's too
>expensive. However it's another to structure an extension in a way that is
>known to be prone to this sort of difficult error. Ease of use matters,
>even in graphics languages, as you obviously know already or you would
>writing PHIGS extensions instead of OpenGL ones (friendly grin).
>
>>
>> -- Michael
>>
>
>Respectfully disagreeing, (and down off my soap box)
>
>John
>
