WinAPI POSIX kompatibel machen
-
Na aber fork() (in der POSEX API) erstellt ja ein neuen prozess
Da ist nurnoch IPC und keione poiter, variablen etc.
-
fdsfs schrieb:
Na aber fork() (in der POSEX API) erstellt ja ein neuen prozess
Da ist nurnoch IPC und keione poiter, variablen etc.Schonmal was von pipe() gehört ? ist auch verdammt einfach zu benutzen.
POSIX sei dank.
-
Und belastet nur unnütz!
Ja ist das nicht toll, und dann wundern wenns langsam läuft!
-
h3t schrieb:
Undertaker schrieb:
h3t schrieb:
Wäre das möglich? Oder gibt es vielleicht sogar ein laufendes Projekt?
DAs wär och was tolles und net immer olle WinAPI.posix ist nicht toll! denk' doch nur mal an solche scheusslichen sachen wie 'pthreads' oder wie prozesse 'geforkt' werden. das kann winapi alles viel besser.
Hast du denn Ahnung von POSIX? Was soll denn scheußlich an pthread udn fork sein?
das waren nur beispiele. schau dir mal an, was mit 'native threads' unter win alles möglich ist, und dann vergleich' es mit der popeligen 'pthread' API.
'fork' ist auch so'n ding. dass ein prozess sich selbst startet, ist meistens ein absoluter sonderfall. genauso 'exec', tauscht den aktuellen prozess gegen einen neuen aus, auch ein sonderfall im 'wirklichen leben'
winapi ist für sowas alles viel brauchbarer --> http://msdn2.microsoft.com/en-us/library/ms684847.aspx
-
IMO ist Threading mit WinAPI doof und genauso doof mit pthreads - nur aus anderen Gründen
-
hustbaer schrieb:
IMO ist Threading mit WinAPI doof und genauso doof mit pthreads - nur aus anderen Gründen
warum nennst du die Gründe nicht?
-
Na weil die GROSS und kleinschreibung verwendet!
Nicht so schön wie die POSEX API oder pthreads-
-
Was will man den mit POSIX bei der WinAPI?
Komm nicht mit Code Kompatibel, mehr als kleine Spielzeug Programme aka Client/Server etc. kriegt man eh nicht hin und da reicht die alte Variante,
wenn es Komplexer wird, wie Webcam capturen, bilder komprimieren und versenden aka DirectX etc. ist POSIX nur noch Überflüssiger Code.
Wenn ich ein umfangreiches Windows Programm schreibe, kann ich mit POSIX null anfangen, alles andere ist Kinderkram.
-
deha schrieb:
hustbaer schrieb:
IMO ist Threading mit WinAPI doof und genauso doof mit pthreads - nur aus anderen Gründen
warum nennst du die Gründe nicht?
WinAPI: keine Condition Variablen, keine "Deleter" für TLS, ...
pthreads: pthread_cond_timedwait/... nehmen ein absolutes Timeout, kein multiple Join, viel zuviele "optional features" die man dynamisch abfragen muss wenn man sie braucht, ...
-
hustbaer schrieb:
WinAPI: keine Condition Variablen, keine "Deleter" für TLS, ...
doch: http://msdn2.microsoft.com/en-us/library/ms682052.aspx
früher gab's die nicht. wahrscheinlich hat m$ sie eingebaut, damit man olle unix-anwendungen leichter portieren kann, denn eigentlich sind cond. variablen überflüssig unter windoows.
-
Ja, ich weiss, ab Vista/Server 2008. Toll, kein Mensch verwendet Vista. Und für Server kann mans gleich ganz vergessen, da Server 2008 wohl erst in 3-4 Jahren halbwegs verbreitet sein wird.
Von daher ist das für mich gleich gut als wenn es sie garnicht gäbe. Wenn das mit einem Update/Service Pack für 2000/XP/2003 kommen würde wäre es was anderes. (Was IMO kein Problem wäre, da die nötigen Änderungen wohl minimal wären)Und für unnötig halte ich die nicht gerade. Condition-Variablen sind deswegen toll, weil dumme/unerfahrene User damit einfach weniger Fehler machen als mit Mutex + Event (man kann z.B. nicht den Fehler machen die Mutex wegzulassen bzw. zu "vergessen" bzw. "wegzuoptimieren"). Klar kann man die Mutex immer noch falsch locken, Multithreading bleibt halt schwer, nur ein klein wenig weniger schwer
Klar kann man Condition-Variablen über Events (mit einigem Aufwand) simulieren, aber wer will das schon? Der Code der dabei rauskommt (der Code der die simulierten Condition-Variablen implementiert, nicht der der sie verwendet) ist entweder falsch oder saulangsam oder zumindest "etwas tricky".
(und ja, wenn man nur "signal_one" braucht dann ist es ganz einfach sich mit Events was selbst zu basteln, bloss ist "signal_all" auch manchmal sehr praktisch)
