Navbar for the Aros wikibook
Aros User
Aros User Docs
Aros User FAQs
Aros User Applications
Aros User DOS Shell
Aros Dev Docs
Aros Developer Docs
Porting Software from AmigaOS/SDL
For Zune Beginners
Zune .MUI Classes
For SDL Beginners
Aros Developer BuildSystem
Specific platforms
Aros x86 Complete System HCL
Aros x86 Audio/Video Support
Aros x86 Network Support
Aros Intel AMD x86 Installing
Aros Storage Support IDE SATA etc
Aros Poseidon USB Support
x86-64 Support
Motorola 68k Amiga Support
Linux and FreeBSD Support
Windows Mingw and MacOSX Support
Android Support
Arm Raspberry Pi Support
PPC Power Architecture
Aros Public License


The arosc library only allows that one task at a time calls a function with the same libbase. AFAIK this does not break any standards. In a later stage a thread implementation will be provided that will to do proper locking around the C functions that need, this should also be usable when you implement your own thread implementation.

Current arosc is not thread-save and the C libs in ABI V1 neither. The best way to get is have a front-end similar to clib2-ts on AROS.

YAM is not using any threading library but its own thread implementation. And even if it would use stuff like pthreads it is the C runtime lib's task to protect its internal stuff from race conditions. No thread framework is able to take this load off the C lib, because this is internal stuff.

For AROS' arosc.library a simple ObtainSemaphore()/ReleaseSemaphore() pair around all implicit and explicit accesses to the __stdio_files list would be a good start. However, there will very probably be many more locations which require enforced single threading to avoid race conditions.

As an intermediate solution already a static link library can be provided that does the proper locking around the function that need it, e.g. arosc-ts (analog to clib2-ts).

Perhaps you should contact Olaf Barthel and port over his clib2 to AROS. I already asked him and he has no objections against such a port. The more systems use clib2 the more possible bugs will be found. I think clib2 C implementation as a static link library would complement the AROS C shared libraries for the programs that depend on certain clib2 peculiarities.

This may be a bit naive, we may need to consider an OpenLibrary() of the AROS C *shared* library for each thread. That eliminates the locking issue, we just need to make the AROS C data area private to each thread.

This may need some headers and linker support, but it should be much easier to implement than a full locking implementation, and would be a lightweight code change. That is not what users want. They want to be able to have one thread do IO with a file opened by another thread.