[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sun, 2004-03-14 at 21:26, Eric Botcazou wrote:
> > I remember, there was some doubts here about changing the behavior of
> > yield_timeslice, and similiar thoughts about it are present on
> > allegro.cc: http://www.allegro.cc/forums/view_thread.php?_id=338662
>
> The change had been recognized as controversial before he was made, no doubt
> about that, so there is no surprise here. Harsh reactions were expected.
>
> But is there any really valid argument apart from "the function doesn't do
> anymore what its name suggests it does"?
Well, not really. I couldn't see a single test-app yet where the old
behavior is needed (and normal busy-looping would be worse). The reason
might be though, that this test-app would only work together with some
"other application" which needs all the CPU time it can get, although my
test-app needs all the time as well and therefore can't use the 4.1.13
behavior. Somehow a contradiction..
> > And when I asked Peter in #allegro what he thinks, he refused to give a
> > clear answer. Here the relevant logs: :)
> >
> > <networm> tjaden: do you also think yield_timeslice shouldn't give up
> > CPU time, like it does in 4.1.13 now?
> > <tjaden> networm, leave me out of this :-)
> > ...
> > <tjaden> i hate computers; i'm going to be a monk
>
> Peter's wisdom is legendary :-)
>
> > So now, I'd tend to change back to the old behavior of yield_timeslice,
> > and provide an al_idle or sleep_timeslice, which would be also used
> > inside Allegro in place of yield_timeslice. (al_sleep I don't like
> > anymore since there's already rest.)
>
> I'm personally still balancing. The only thing I'm sure of for the time
> being is that the behaviour should be consistent across all platforms.
>
Yep. And I'm sure that my programs and Allegro itself should use the
4.1.13 behavior, and I don't see where I'd ever want the old behavior. I
just somehow have a bad conscience since I made this change and maybe
for someone the Allegro API might get worse by it..
--
Elias Pschernig <elias@xxxxxxxxxx>