APIs: POSIX versus Classic

[Joel Sherrill]

On 08/05/2013 02:43 AM, Sebastian Huber wrote:
> Hello,
>
> the only reason why the POSIX API is optional is that you can save some code
> and data space in applications that don't need it.  It helps also to reduce the
> code size to be reviewed.
But underneath they are both instances of SuperCore Thread with
different attributes set. There is some extra data to track the POSIX
API features like signal sets, etc. and the minimum code added is
mostly initialization.

The overhead used to be a lot worse. But anything you can leave
out is better.

The Classic API is based on a proposed standard that was effectively
pSOS+'s API. That style of API is visible in RTEMS, Nucleus, and ThreadX.
It has some features that are not present in POSIX.

You can mix APIs. A POSIX thread for example can use a Classic API
Rate Monotonic period object. Or a Classic API task can use a
POSIX mutex.

It also means that you port a library once and any style task/thread
can use the library without worrying about what RTEMS services you
used to port it.

The key benefit is being able to share code with UNIX-based hosts
easily. :)

Sorry to pile on late but this mix of APIs and standards really has
benefits.
> On 2013-08-05 06:28, Nick Withers wrote:
>> Hi all,
>>
>> Quick one (hopefully :-P): Is there a "preferred" RTEMS API for new
>> code? The POSIX API's considered production-ready, I believe...?
> The asynchronous cancellation is not production ready from my point of view,
> but this is a questionable concept on its own.
>
>> Ideally, I'd use the POSIX API for increased portability, methinks.
>>
>> Cheers!
>>
> The POSIX thread support enables you to use a lot of common third party libraries.
>


-- 
Joel Sherrill, Ph.D.             Director of Research& Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available               (256) 722-9985