Re: [MiNT] threads (was: UNIXMODE defaults)

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Monday 05 July 2010, Alan Hourihane wrote:
> On Mon, 2010-07-05 at 14:52 +0200, Jo Even Skarstein wrote:
> > Ozk made some stuff that made use of threads about 10 years ago, but I
> > don't know how he did it. Perhaps he can explain if he follows this
> > list these days.
>
> Right, this is GNU pth. Which has a "pthreads emulation". This is all in
> user-space with jmp table fudging. No kernel support at all.

Any idea how well that worked on MiNT?

Sparemint version 2.0.0 seems to be fairly up to date:
	http://www.atariforge.net/sparemint/html/packages/pth-devel.html

I didn't see any major issues in the changelog for later upstream releases
(latest is 2.0.7 and almost all changes were adaptation for newer GNU
tools versions):
	http://www.gnu.org/software/pth/


On Tuesday 06 July 2010, m0n0 wrote:
> Multi-Threading (posix compatible) would probably make porting some apps
> more easy. But I think it is not really needed often - altough many
> programmers use it. But probably these programs could also be rewritten
> to work without multi-threading.

Use of threads often affects the whole architecture of the program.  In many
cases you would need to invest a huge amount of time to understand the code
before you can do that kind of a change.  It would be large, hard to test
(concurrency issues...) patch with probably no chance of getting it to
upstream.  


> Maybe even cleaner & more stable? ,... 

Possibly, depending on the case, but large changes always destabilize
software (until the new issues are fixed). In some cases where data needs to
be communicated often between threads and shared memory is not suitable, it
would be a performance issue too.


On Tuesday 06 July 2010, Vincent Rivière wrote:
> For a preemptive multitasking system, the underlying OS must provide
> some way to interrupt a process. I don't know if this could be done
> cleanly via signals. This is the only tricky part.

LinuxThreads used signals with N:M threading model.  Current Linux NPTL
threads library uses 1:1 model, it was adopted after Linux kernel process /
threading scalability issues were fixed.  LinuxThreads documentation
mentions not knowing to which thread the signal gets delivered as problem,
but that might be due to the N:M threading model.  Maybe it's not an issue
with the libpth N:1 model?

Signal handlers are also strictly limited in what they can do.  POSIX
standard guarantees only very few C-library functions to be signal-context
safe[1].  I have no idea whether those functions (listed e.g. in the Linux
signal(7) manual page) are signal safe also in MiNTlib.


	- Eero

[1] e.g. anything calling allocs or something else changing internal
C-library structures can potentially corrupt the process memory.  Signal
handlers are trickier than threading because there's no locking mechanism.
Many open source programs I've seen have non-robust signal handlers.
(Gtk programs call gtk_main_quit() or use non-recursive locking in signal
handler etc).