Re: [MiNT] pthreads (was mono)

[Eero Tamminen <oak@helsinkinet.fi>]

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.

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.


> 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.

On Linux app can also change its thread stack size on runtime (at least
decrease it).


> 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...


	- Eero


> > Somebody should provide these for FreeMiNT on the CF machine (and
> > perhaps on 040/060) or you
> > risk porting modern packages will always be great pain + rarely ever a
> > possibility for upstream
> > acceptance.
> >
> > Standa
>
> There are a lot of people around atm, and I expect at least for the
> next 12 months. Something will happen here I have no doubt. It might
> get done quicker if peeps knew what was needed, and could supply
> chucks to get the project(s) completed faster, as opposed to relying
> on one person, or team.
>
> One thing I have noticed about Atari ST/Mint development (atm), is
> that most people either have family (kids), school or job, which means
> they dont have a lot of time to dedicate to projects. However, if they
> could spend a few hours here and there supplying pieces, then even a
> relatively large project could be achieved.
>
> There are a few like me who do have the time to put into documenting
> what is needed and where (and doing other boring stuff). I am
> constantly on the look out for things that can fill or help fill a
> need in Atari ST/Mint development, especially source code, and have a
> large collection atm.
>
> If I can collect such things as you have done with mono, document what
> is needed, and where, which is part of providing cross-referenced docs
> and dev docs, then others can take a look at specific things as time
> allows, instead of "re-inventing the wheel" or ending up with another
> dead project.
>
> I, to do these things, and others, to find, discuss and provide these
> things, need to have an infrastructure which can support these types
> of initiatives. The beginning of which is a useful wiki.
>
> The other thing I note about ST/mint development, is that one person
> often takes on the job of providing something, but as pointed out
> above, they do not have the time to commit 100% to getting it
> completed ASAP.
>
> In this case (bare with me here people), the wiki is a good example.
> Yes content structure and clarity are required. But if only one person
> is allowed to provide the content, then what is the point of using
> wiki in the first place. In this example, everything that was needed
> could have been added within a week by many people, and the person
> taking responsibility for it could have re-organised everything, once
> a layout was decide, others could then have assisted in the
> restructuring.
>
> In this case also, wiki is less about structure, and more about
> structure evolution. There is only ever a small set of key things
> needed documentation wise (for any project), everything else is an
> added bonus, and evolves as needed or as time permits.
>
> So, with that in mind, I hope to start providing these currently
> missing access points for projects, documentation, help docs, dev
> environments, required downloads, or quickstart guide, in such a way
> as others can both use and edit/add as there time permits..
>
> ATM it is differcult to provide the required integration simply
> because I believe it should not reside on my servers. The majority of
> information is physically available on one server, and to that should
> be added more dead and abandoned projects (like mono mentioned here)
> that have relevance. This should extend to at least a minimum set of
> full apps and libraries that allow full OS usage and/or development
> (including porting)
>
> However the management of all of this needs a user system like wiki,
> which does not need any human response or confirmation in order to
> sign up and contribute, and yet keeps history and makes branching
> possible (for dev work), without the need for setup from any one
> individual who may otherwise be unavailable for whatever reason.
>
> OK, nuff for the moment, every minute spent replying to mailing lists
> eats into the time I need to provide the above. To anyone associated
> with comments made in this, please do not take offense, it was not
> meant in that way, and is unproductive, which is counter to the
> essence of this post, working solutions are always better
>
> If anyone else has dead projects (I already know about the abandoned
> projects on the ICQ site) or has incentive to provide written material
> (ala http://wikipendium.free.fr/) please speak up, there are a ton of
> areas to contribute too, many of which are not boring :)
>
> Paul