Re: multithreaded callbacks (was Re: [AD] de fourium pointium ohium)

[George Foot <gfoot@xxxxxxxxxx>]

On Wed, Aug 01, 2001 at 07:49:33PM +0200, Eric Botcazou wrote:
> > Most user callbacks won't be affected greatly by running in parallel
> > threads, so for now, and maybe for ever, I think we should just
> > acknowledge the problem (i.e. state in docs) and tell users to find their
> > own synchronisation devices.
> 
> I agree with you when you're saying that this problem doesn't have a big
> impact on most user programs so, unless someone quickly comes up with a very
> brillant idea, I think we shouldn't rush ourselves into a decision before
> the 4.0.

I agree that it doesn't have much impact, and whatever happens
we can't preserve compatibility with current DOS programs.  We
can't always emulate the old DOS functionality, we should only
do that when we want to... er, I mean, when it's convenient. :)

Doing nothing is obviously the easy way out, for now, but I
don't think we should rule out adding the simple mutexing API
before Allegro 4.0; it's hardly a new feature, and it's so
simple I doubt we could put any bugs in it. ;)

> However, we have made some progress: option (0) seems now to be irrealistic
> so basically we end up with (1a) (total control in the hands of the user)
> and (1b) (no control or a shared control).

I don't like automatic locking any more, and I thought we
decided against it anyway.  I think the decision now is simply
between wrapper routines in Allegro vs user calling threading
library directly.  I think wrapping is the best route now (how's
that for a U-turn?), so long as the wrappers are small,
lightweight, and simple to use.  Which I'm sure you guys agree
with too. :)

I don't think they should be advertised for non-Allegro use
though -- I think if the user is doing his own threading, he
should use the mutexing from whatever threading library he has
to synchronise his own threads.  Allegro's functions should only
be used with Allegro-created threads (e.g. timers) and I think
the synchronisation there should only be between those threads
and the main thread.  This way we don't have to worry about
whether the threading functions work with Windows pthreads, for
example -- they just need to work with normal Windows threads.

> George, I don't really understand your prejudice against (1a): I wouldn't
> call 4 little functions yet another thread API. Allegro provides (actually
> several ports) a somewhat twisted threading model through timers, I don't
> see why we shoudn't make it as safe as possible. If you want to see a true
> new thread API, take a look at SDL. However, I'm not sure this solution fits
> very well into Allegro's philosophy of ease-of-use.

Sorry, I think I overreacted a bit. :)  But think of it this
way:  I don't want to see Allegro's threading routines
preventing the user from using another library for their own
threading.  This problem occurs with other areas of Allegro --
it's really hard to use Allegro's graphics with another
library's input handling.  It's easy to criticise SVGAlib for
taking control of the Linux console, because that handling is
getting in the way of Allegro, but Allegro itself does exactly
the same thing.  I think I'm just wary of forcing users to use
library functions instead of other alternatives when it's
unnecessary.  It feels a bit like sucking people in, the
Microsoft way. :)  Users are quite free to copy-and-paste code
from Allegro, but it seems more and more that they can't
(easily) use just a few parts of it and have no impact from the
rest.

Hmm, maybe this is just a Unix problem though.  A few more
examples if you like:  Allegro intercepts the `main' function on
Linux and (I think) doesn't even use the argument list; it also
intercepts in on generic Unix, purely to be able to tell you the
path to your executable -- which you probably don't even care
about.  If you want Allegro's keyboard, mouse, or joystick input
in Linux, you have to grab the console too.  Same goes for
timers.  If you don't want to grab the console, you have to use
SYSTEM_NONE which can really only do maths, and graphics to
memory bitmaps.

This is going off the topic of the thread (and I don't want to
distract from the threading issues, I think we should implement
the mutexing API as soon as possible), but do people think these
things need addressing?

George