< Aros‎ | Developer/Docs


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.