[PATCH] D11781: Refactored pthread usage in libcxx

[Asiri Rathnayake via cfe-commits]

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.
>
>
> Thanks!
>
> If you meant the mbed OS [1], I think it is still single-threaded (although that might change in the near future [2]). Most of our customers (of armclang) have proprietary RTOSes, but we might be able upstream a sample implementation (I'm thinking Keil RTX [3], but need to double check a few things), if it seems generally useful to the community.
>
> Cheers,
>
> / Asiri
>
> [1] https://www.mbed.com/
>  [2] https://www.mbed.com/en/development/software/mbed-os/ ("...we intend to re-introduce it in 2016")
>  [3] 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.

Cheers,

- Asiri


Repository:
  rL LLVM

http://reviews.llvm.org/D11781