> >> POSIX w embedded nie jest dobry.
> > Nadal nie napisałeś, dlaczego.
> Wiele systmów embedded:
> a) nie ma plików
> b) nie ma procesów
> c) nie ma rurek
> d) nie ma sygnałów
> e) nie ma konsoli
> f) a wniej interaktywnych poleceń

No i?
Taki przykładowy QNX jest oparty o mikrojądro, gdzie te wszystkie rzeczy powyżej to
osobne usługi, których można nie mieć, to jest kwestia konfiguracji. I niepotrzebnych
rzeczy nie ma, zwłaszcza w systemach embedded.
Nie zmienia to faktu, że nadal QNX jest POSIX.
I dlatego dalej nie rozumiesz.

> Ale ma 40 programów w dildo

Zaczynam mieć wrażenie, że to jedyna rzecz, o której masz coś do powiedzenia.

> POSIXa w jakiejś implementacji ciężko będzie formalnie weryfikować

Sam sobie zaprzeczasz. "W jakiejś implementacji"? A jeśli mam formalnie zweryfikowaną
implementację, to czy w takiej implementacji będzie ciężko zweryfikować? Nadal nie
odróżniasz API od implementacji. POSIX to tylko API.

> Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze,

A jest formalnie zweryfikowany? Bo widzisz - POSIX to API. Natomiast FreeRTOS to
konkretny system. I ten konkretny system nie jest zweryfikowany, nawet nieformalnie.
Dlatego zdecydowanie nie chcesz go w respiratorze.
(ale możesz chcieć SafeRTOS, którego napisali od nowa w tym celu)

> Bo POSIX jest niezwykle trudny do weryfikacji. Z powodu komplikacji
> swojego API.

Od kiedy API utrudnia weryfikację? W jaki sposób?

> > Mogę mieć dobrej jakości implementację
> Możesz. A masz?

Przecież już pisałem.

> > Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX.
> A na freeRTOS? A na Windows CE?

A tam nie zadziałał od ręki, bo autorzy uznali, że musi być ourMutexCreate(), zamiast
pthread_mutex_init().

> Ok, ustalmy wobec tego że masz program *częściowo* przenośny. Tak lepiej?

Nie wiem, czy lepiej. Na pewno program napisany pod API POSIX jest bardziej przenośny
(bo działa na wielu systemach), niż program napisany pod FreeRTOS (bo działa tylko na
jednym).

> W sumie
> bez znaczenia czy masz pthread_mutex_init nazwany dupa. Istotne jest że
> w innym systemie (niezgodnymz POSIX) może w ogóle nie itnieć inicjacja
> poza miejscem deklaracji, albo istnieć przyjmująca paramter resursive.

Może czy istnieje? Pokaż na przykładzie FreeRTOS (skoro już o nim mówimy i chcesz go
w respiratorze).

> Dlatego masz class MyMutex

To mam z innego powodu. Otóż w programie C++ wolę mieć bardziej zunifikowane idiomy.
Np. zwalnianie tego muteksa w destruktorze. Ale robię to z powodu *podniesienia*
poziomu abstrakcji, a nie z powodu zapewnienia przenośności. Do przenośności
wystarczyłby POSIX, gdyby twórcy januszowych RTOSików nie mieli przerostu ego i
presji na wymyślanie własnych nazw.
Dlatego chciałbym mieć *jedną* implementację mojej klasy MyMutex. A nie kilka
różnych.
(oczywiście teraz mamy też std::mutex, ale dyskusja jest ogólna)

> > zrobić mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest
łatwiej dostępny.
> A na windowsie?

"U mnie działa"?
Jeśli trzeba puścić unit testy, to Cygwin jest do tego jak najbardziej wystarczający.

> Na codzień piszę kod na POSIXie i
> Windowsie *jednoczesnie*. Powiedzmy że mam zielone pojęcie gdzie POSIX
> jest przenośny. Powiedzmy że nieco powyżej średniej, mam to pojęcie.
> Nijak nie udało mi się zawołać funkjci Posixowych w Windowsie.

"U mnie działa"?

> Zgadnij dlaczego mamy (wreszcie) std:: z obsługą wątków, i to nie jest
> POSIX like API.

A niby jak by miało być "like"? POSIX to jest API dla języka C. Logiczne jest, że API
w std:: będzie inne. I dobrze.

> Najwidoczniej ktoś kombinuje jak ja - abstrakcja na OS.

Pominąłeś szczegół: ktoś z tym std:: kombinuje, że standardy są dobre. I ma nadzieję,
że autorzy implementacji będą tego standardu przestrzegać, bo od przestrzegania
standardu zależy przenośność końcowych programów, jak też obniżenie globalnych
kosztów. Nie przypisuj sobie tego pomysłu, bo do tej pory byłeś od niego daleko.

> > Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest.
> Bo jest nieprzenośne na inne embedded.

Jest przenośne bardziej (również na embedded), niż ourMutexCreate, który w ogóle nie
jest.

> Ty najwidoczniej możesz sobie pozwolić na ogarnieniae abstrakcji w
> POSIXowym OSie.

Też nie mogę. Bo ktoś olewał standardy.

> Stąd różne opinie. Moja w tym wypadku jest mojsza i tyle.

Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być. Stąd
nieporozumienie. ;-P

--
Maciej Sobczak * http://www.inspirel.com