Re: [MiNT] pthreads (was mono)

[Paul Wratt <paul.wratt@gmail.com>]

On Sun, Jan 31, 2010 at 5:31 AM, Eero Tamminen <oak@helsinkinet.fi> wrote:
> Hi,
>
> On Sunday 31 January 2010, Paul Wratt wrote:
>> Pthreads is another "kettle of fish", and may require complete
>> redo/overhaul of multitasking parts of kernel. This is a tough one
>> because there are not many people who can do such things even outside
>> of ST/mint development.
>
> Linux has two threads implementations.  The old linuxthreads implementation
> and the new NPTL one.
>
Yep, I know about these, specifically NPTL which is compulsary for
compiling linux kernel 2.6.26+, which can cause no end of problems if
you are still running 2.6.18 or one of the 2.4 kernels..

> Linuxthreads uses M:N userspace / kernel thread mapping, NPTL 1:1 mapping.
> Linuxthreads is slower and doesn't scale as well (but does somebody have
> multicore MiNT machine and SMP safe MiNT?) and it's more fragile as (if I
> remember correctly) it uses signals to wake up the other threads and
> application has no way to know which thread the signal got delivered.
>
> New threading code in C-library also uses new Linux kernel facilities like
> futexes (only if the lock would block, code enters kernel).
>
> It's a huge can of worms.
>
Without at least a virtual dual 68k, anything SMP is theory, even if
coded for. However, the lack of MP 68k is more about a lack of a
useful (or compatible) MiNT kernel, as there are some hardware
alternatives available.

Forgetting the lack of test setups, is it nescesary for apps to use
threading, and just let the kernel do it, or is that the point of apps
like Quake 2/3, Photoshop, etc, in that they can use SMP directly. Is
it not just ports that would be restricted by the lack of SMP/thread
support?

>> One way I have proposed to tackle these issue related to porting at
>> least, is to use dummy or replacement libraries, so the functions used
>> in code dont need to change, and the lib supports what it can, and
>> does other things where the OS cant handle it.
>
> Another issue is that on Linux desktop the current default thread stack size
> is 8MB (few years ago, 2MB).  Last time I used threads on MiNT (on 90's),
> MiNT provided 4kB thread stack.  Programs expecting MBs of stack on threads
> are not going to work on something having just kBs of stack.
>
so either apps wont work, or they may run with restrictions.

When you compile using any MS visual dev, you chose your threading
model. Whats the likelihood of being able to compile apps for mint
that will still work, even with reduced thread stack?

> On Linux app can also change its thread stack size on runtime (at least
> decrease it).
>
When you have megs for stack size, being able decrease it makes sense

>> Its not a perfect fix, and something like pthreads would probably just
>> be easier to add the missing parts to kernel to get the correct
>> support.
>
> Err...
>
.. about adding a thread library that was not the real deal, it would
take just as long to add the missing parts to mint and port pthreads
anyway..

>
>        - Eero

Cheers

Paul