[PATCH] D11781: Refactored pthread usage in libcxx
Asiri Rathnayake via cfe-commits
cfe-commits at lists.llvm.org
Wed Apr 20 01:49:10 PDT 2016
rmaprath added a comment.
In http://reviews.llvm.org/D11781#403349, @rmaprath wrote:
> In http://reviews.llvm.org/D11781#403343, @theraven wrote:
> > In http://reviews.llvm.org/D11781#403335, @rmaprath wrote:
> > > For us (ARM), a threads porting layer is important on several RTOSes (where a full-blown pthreads implementations is not available). I will see if I can publish one of those porting layer implementations, but perhaps a windows porting layer is more interesting to the community, in which case I'll look into hacking one up (unless of course, if @espositofulvio has already got one).
> > I'd be equally interested (and willing to review) an mbed implementation.
> If you meant the mbed OS , I think it is still single-threaded (although that might change in the near future ). Most of our customers (of armclang) have proprietary RTOSes, but we might be able upstream a sample implementation (I'm thinking Keil RTX , but need to double check a few things), if it seems generally useful to the community.
> / Asiri
>  https://www.mbed.com/
>  https://www.mbed.com/en/development/software/mbed-os/ ("...we intend to re-introduce it in 2016")
>  http://www.keil.com/rl-arm/kernel.asp
I stand corrected, mbed already has an RTOS layer: https://developer.mbed.org/handbook/RTOS. I'm not very familiar with mbed (obviously). I will do some digging to see how difficult it would be to port libcxx to mbed (we already build libcxx for cortex-m bare-metal systems, so this shouldn't be that hard).
After reading through the past threads, providing a windows thread porting layer sounds like a useless thing, given that getting libcxx to build on windows itself is a rather large piece of work.
More information about the cfe-commits