On 09/01/2021 16:48, Maciej Sobczak wrote:
>> 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?

To oznacza że POSIX nie jest dobrą abstrakcją na OS b wymaga tego
wszystkiego aby być POSIXem. Inaczej nie jest POSIXem.

> 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.

Każda konfiguracja, inna niż *wszystko*, nie jest już POSIXem.

> I niepotrzebnych rzeczy nie ma, zwłaszcza w systemach embedded.

To po co tam wciskać POSIXa skoro używa się 5% jego api?

> Nie zmienia to faktu, że nadal QNX jest POSIX.

Jak zrobisz make all_shit_included to na pewno jest.

>> Ale ma 40 programów w dildo
> Zaczynam mieć wrażenie, że to jedyna rzecz, o której masz coś do powiedzenia.

Nie, to dwa odległe światy: dilda i respiratory. jedne można programować
byle jak, inne wymagają cięzkich certyfikacji. W obu stosuje sięte same
procesory, techniki, abstrkacje, i w ani jednym z nich nie ma POSIXa.

>> POSIXa w jakiejś implementacji ciężko będzie formalnie weryfikować
> Sam sobie zaprzeczasz. "W jakiejś implementacji"?

Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior. To jak się
zachowa, zależy od implemetacji, ba, nawet od wersji jądra, bibliteki,
interakcji usera czy co tam na niego wpływa.

> A jeśli mam formalnie zweryfikowaną implementację

Wątplię, aby ktoś formalnie weryfikował POSIXa. Z uwagi na UB. Ale może
sie mylę, znasz przykład?

>, to czy w takiej implementacji będzie ciężko zweryfikować?

Tak, ponieważ posix generuje bardzo dużo stanów które wymagają formalnej
oceny przejścia i obsługi. Tan interfejs jest bardzo ciezko weryfikować.

Jeśli z ::read może wylecieć 20 róznych stanów to nie jest to dobre API.

> Nadal nie odróżniasz API od implementacji. POSIX to tylko API.

Więc sprawdź jak zachowuje się na różnych systemach. No wiec różnie.

>> Jednak wolę dalej FreeRTOSa nad POSIXa w respiratrorze,
> A jest formalnie zweryfikowany?

Jest możliwy do weryfikacji łatwiej niż POSIX. I prawdopodobnie nie
używany i tak, bo to zabawka do dildo. Podobnie jak POSIX na mainframes.

> Bo widzisz - POSIX to API. Natomiast FreeRTOS to konkretny system.

I tu wchodzi abstrakcja, cała na biało.

> 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)

Który to SafeRTOS jest bez wątpienia POSIX like. I w dodatku bazujący na
API FreeRTOS :D Ależ to życie jest złośliwe.

>> Bo POSIX jest niezwykle trudny do weryfikacji. Z powodu komplikacji
>> swojego API.
> Od kiedy API utrudnia weryfikację? W jaki sposób?

W taki sposób:

switch ( fooResult )
{
case Error:
case OtherError:
case UlikelyError:
case SomethingBroken:
case DoItAgainPlease:
case MabyeLater:
case OKButNotQuite:
case Almost:
case NeedRest:
case Interrupt!:
}

>>> 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().

Nie, autorzy mają inny rodzaj mutexa. Wątku. Rurki. To nie kwestia nazw,
tylko użytku.

>> 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).

A program napisany w Qt jest jeszcze bardziej przenośny od tego w POSIXie.

>> 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?

Na w tym miejscu jest std::mutex mutex; bez śladu free function.

Na przykład obok jest CreateMutex biorący 3 parametry.

> Pokaż na przykładzie FreeRTOS

Nie, pokaże na dowolnym innym przykładzie, aby obalić Twoją tezę o braku
sensu abstrakcji na inicjacje mutexa.

>> 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.

Robisz to z obu powodów. std::foo jest przenośne z definicji.

> Do przenośności wystarczyłby POSIX

Nie chcesz takiej przenośności. POSIX to gówno. Pod wieloma względami to
zamrożone workaroundy z lat 70tych.

>, gdyby twórcy januszowych RTOSików

A twórcy januszowych Windowsów?

> Dlatego chciałbym mieć *jedną* implementację mojej klasy MyMutex. A nie kilka
różnych.

Nie ma takiej potrzeby. I tak masz dwie co najmniej. Przecięz masz
jeszcze mocka do testów.

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

Bo robisz je na cygwinie czy nie masz?

> Jeśli trzeba puścić unit testy, to Cygwin jest do tego jak najbardziej
wystarczający.

Ano właśnie, znalazłeś adapter do systemu operacyjnego. Bardzo milutko.
Nie sprzedasz jednak aplikcji napisanej na cygwinie, pozerkaj jak bardzo
wieli ból dupy mają twórcy cygwina z powodu niekompatybilnosci POSIXA z
WinApi i dlaczego w paru miejscach maja spinlocki.

>> 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"?

Nie, działa Ci w cygwnie. I nie dział wydajnie. Rownie dobrze mógłbyś
powiedzieć, że Ci działa w emulatorze odpalonym na windowsie. Ten sam
poziom "działania na windowsie".

>> 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"?

Bo to taka znakomita abstrakcja. Kazdy by chciał POSIXa w każdym dildo i
respiratorze, ale świat wyglada inaczej.

> POSIX to jest API dla języka C.

Nie tylko. Również dla ograniczonej klasy systemów, w tym w
szczególności posiadajacych konsolę z interakcją z userem.

>> Najwidoczniej ktoś kombinuje jak ja - abstrakcja na OS.
> Pominąłeś szczegół: ktoś z tym std:: kombinuje, że standardy są dobre.

Tak, ktoś kombinuje aby były *naprawdę* abstrakcyjne, a nie ściema, jak
POSIX.

> Nie przypisuj sobie tego pomysłu, bo do tej pory byłeś od niego daleko.

Możesz powiedzie gdzie go sobie przypisuje?

>>> 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.

Ale jest, to 1 linijka kodu dla POSIXa i 1 linijka kodu dla WinAPI. To
się nazywa adaper i itnieje w każdej implementacji interfejsu. W POSIXie
też istnieje adapter z pthread do przestrzeni kernela.

>> Ty najwidoczniej możesz sobie pozwolić na ogarnieniae abstrakcji w
>> POSIXowym OSie.
> Też nie mogę. Bo ktoś olewał standardy.

Nie olewa standardów. POSIX to jest taki standard z przypadku. Microsoft
nie ma śadu powodu aby go używac. Przyznał to Bill kiedy mówił że API
windwosa jest jedyne w swoim rodzaju i to jest *najważniejsze* co
Windows posiada. Inność. Dzieki czemu jest typowym vendor-lockin. Na
szczęscie od dawna potrafimy to obejść, dzięki abstrakcji na OS.

>> 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ć

Idealista.

Świad składający się z samych POSIXów byłby wyjątkowo gówniany, tak samo
jak składający się z WinAPI. Oba to zamrożone dawno temu workaroundy, w
tym wręcz krytyczne debilizmy.

Tupanie nogą że świat nie jest POSIXowy i na siłe uzależnianei się od
tego kipeskiego API nie jest specjalnie profesjonalne.