Re: [AD] retrace_proc is wrong

[Peter Wang <tjaden@xxxxxxxxxx>]

Chris wrote:

> Peter Wang wrote:
>
> > retrace_proc works just like a "timer" callback, so could be run from 
> > a background thread.  This means things like altering the palette 
> > should not be allowed
>
>
> Why? As long as you don't set the palette in two threads at once I 
> don't see a real problem. Though yes, it's usefulness is still 
> questionable.


For example in the Unix sigalrm port, retrace_proc can be called in the 
middle of some Xlib operation.  ex3buf then goes off and calls 
_set_color(), so you get an Xlib async error.  I guess some locking 
and/or delaying of calling the retrace_proc can deal with that (like 
what we do with timer callbacks), but (1) the point of the retrace_proc 
is that it is called at a very specific rate, and (2) we wouldn't 
recommend palette changing in timer callbacks either.

> > I suggest we deprecate retrace_proc in the unstable branch.  Given 
> > its uselessness, I would like to see it removed.  It could be 
> > retained as a DOS-only feature, but deprecated.
>
>
> Can you deprecate variables? I think doing that would also cause 
> Allegro to spit out a bunch of deprecation warnings in where it itself 
> uses it (since it would still need to maintain compatibility by using 
> it). There is a flag to make GCC not warn about using derprecated 
> stuff, but then I fear we wouldn't catch everything in the future when 
> we deprecate more things.


"Deprecate" means we discourage it in the documentation (which is 
roughly equivalent to a specification of sorts).  Turning on the gcc 
attribute (for example) is only a side-effect in the implementation.  
You can have the former without the latter.

Peter