Re: [MiNT] USERDEF stack size

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On torstai 23 joulukuu 2010, Jo Even Skarstein wrote:
> On Wed, 2010-12-22 at 18:28 -0500, Mark Duckworth wrote:
> > To be fair this is to suggest GEM supports full multithreaded
> > operation, including multiple threads interacting with user interface
> > elements?
> 
> No, that's not the advantage of threading. Two threads shouldn't fiddle
> with the same dialog or button. But you can spawn a thread that handles
> parts of the UI, e.g. the download status dialog in a ftp client or the
> copy progress dialog in a desktop.

It's much cleaner if the main thread handles all the UI stuff
and threads handle things that either:
- can block (e.g. network access or certain kinds of disk accesses)
- can take a lot of CPU & time otherwise (e.g. chess engine)

Threads should handle only things that are very well contained and have as
few interaction points (also through libraries they use) with other threads
/ main program.

Some other things to consider:
- how thread-safe MiNTlib is
- the size of thread stacks (4kB?)


> The thread then calls appl_init and
> get its own apid. The AES won't even know that this is a thread.
> 
> > Even windows doesn't support that, all UI code has to be in the main
> > thread.  Kind of reaching for a feature nobody needs?
> 
> It can be very useful, but due to all the re-entrancy problems with most
> common libs it's hard to use in real life.

And if the threaded part of code isn't _very_ well isolated (goes through
foobar libraries), it's going to be hell debugging race conditions. On Linux
one at least have Valgrind's Helgrind & DRD plugins to debug things like
that, on MiNT... How well even Gdb works with threads?


	 - Eero