Welche Green-Threads-Bibliotheken sind für C verfügbar, die mit der Leistung und Benutzerfreundlichkeit der Green-Threads von Haskell mithalten können? [closed]

Ich bin es gewohnt, mich auf GHCs zu verlassen forkIO für portable leichte Threads beim Programmieren in Haskell.

Was sind äquivalente Bibliotheken für C, die die gleiche Skalierbarkeit und Benutzerfreundlichkeit bieten können?

Insbesondere benötige ich C-Äquivalente von mindestens den folgenden zwei Funktionen.

forkIO     :: IO () -> IO ThreadId
killThread ::             ThreadId -> IO ()

Ich gehe davon aus, dass es für meine Anwendung ausreichen würde, wenn Threads nur bei Blockierungsvorgängen eingeschaltet würden, anstatt zwangsweise suspendiert zu werden, da alle Threads sehr häufig für Netzwerk-IO blockieren und ich nur die nutze splice Systemaufruf, um den Linux-Kernel aufzufordern, Daten zwischen Sockets zu verschieben.

Aktualisieren

Dieses Papier hat Abbildungen und Tabellen zum Vergleich

• GNU-Pth
• Protothreads
• PM2-Paket

mit Ergebnissen zugunsten von Protothreads. Da ich keine verwendet habe und es möglicherweise auch andere Bibliotheken gibt, würde ich gerne von jemandem hören, der solche Bibliotheken verwendet / entwickelt hat.

libMill ist wahrscheinlich das, wonach Sie suchen: http://libmill.org/

Es implementiert Threads auf Benutzerebene im Stil des Go-Lang-Kanals.

Und es wird von dem superschlauen Martin Sústrik, dem Schöpfer von ZeroMQ, entwickelt http://250bpm.com/. Also muss es gut sein ☺

Ich habe weder die Kommentare für den folgenden Code noch irgendwelche Beispiele mehr – dies ist eine portable (Pseudo-) Thread-Bibliothek, die als Präprozessor-Makros implementiert ist

     typedef struct
     {
     unsigned int magic;
     unsigned short ctx;
     unsigned char is_destroyed;
     }
     _run;

     typedef struct
     {
     unsigned int magic;
     unsigned int cnt;
     }
     _sem;


     #define aa_RUNNER_WAITING             0
     #define aa_RUNNER_YIELDED             1
     #define aa_RUNNER_EXITED              2
     #define aa_RUNNER_ENDED               3

     #define aaRunnerCreate(rp)            (rp)->magic="runr"; (rp)->ctx=0; (rp)->is_destroyed=NO
     #define aaRunnerDestroy(rp)           (rp)->is_destroyed=YES

     #define aaRunnerThread(args)          C args
     #define aaRunnerBegin(rp)             { C yflag=YES; if(yflag) {}  switch((rp)->ctx) { case 0:
     #define aaRunnerEnd(rp)               } yflag=NO; if(yflag) {}  aaRunnerCreate(rp); return aa_RUNNER_ENDED; }

     #define aaRunnerWaitUntil(rp,condx)   do  { (rp)->ctx=__LINE__; case __LINE__: if(!(condx))  { return aa_RUNNER_WAITING;  }  } while(0)
     #define aaRunnerWaitWhile(rp,condi)   aaRunnerWaitUntil((rp),!(condi))
     #define aaRunnerWaitThread(rp,thr)    aaRunnerWaitWhile((rp),aaRunnerSchedule(thr))
     #define aaRunnerWaitSpawn(rp,chl,thr) do { aaRunnerCreate((chl));  aaRunnerWaitThread((rp),(thr)); } while(0)

     #define aaRunnerRestart(rp)           do { aaRunnerCreate(rp); return aa_RUNNER_WAITING; } while(0)
     #define aaRunnerExit(rp)              do { aaRunnerCreate(rp); (rp)->magic=0; return aa_RUNNER_EXITED;  } while(0)

     #define aaRunnerSchedule(f)           ((f)<aa_RUNNER_EXITED)
     #define aaRunnerYield(rp)             do { yflag=NO; (rp)->ctx=__LINE__; case __LINE__: if(!yflag||!((rp)->is_destroyed))  { return aa_RUNNER_YIELDED;  }  } while(0)
     #define aaRunnerYieldUntil(rp,condi)  do { yflag=NO; (rp)->ctx=__LINE__; case __LINE__: if(!yflag||!(condi)) { return aa_RUNNER_YIELDED;   }   } while(0)

     #define aaRunnerSemInit(sp,c)         (sp)->magic="runs"; (sp)->cnt=c
     #define aaRunnerSemWait(rp,sp)        do { aaRunnerWaitUntil(rp,(sp)->cnt>0); --(sp)->cnt;  } while(0)
     #define aaRunnerSemSignal(rp,sp)      ++(sp)->cnt

Verwenden Sie POSIX-Threads. Sie sind in jeder modernen Implementierung “grün”, nicht im Sinne von “Grünen Fäden”, sondern im Sinne von leicht und effizient. Es gibt keine portable Möglichkeit, Ihre eigenen Threads auf einfache C- oder POSIX-Minus-Threads zu rollen. Wie OP erwähnt, gibt es einige Bibliotheken, die grüne Threads/Co-Routinen auf nicht-portable Weise implementieren (oft trotz der Behauptung, Portabilität).

Der am nächsten tragbare Ansatz ist die Verwendung von makecontext/swapcontext, und leider kann dies nicht gut funktionieren, da Systemaufrufe ausgeführt werden müssen, um die Signalmaske bei jedem Wechsel zwischen “Threads” zu speichern / wiederherzustellen. Dies macht das Umschalten zwischen “grünen” Threads teurer als einen Kontextwechsel zwischen Kernel-Level-Threads in einer “echten” POSIX-Thread-Implementierung und negiert im Grunde jeden behaupteten Vorteil von “grünen Threads”.

Nicht-portable Ansätze, die sich nicht um die Signalmaske kümmern, könnten maschinenspezifisches asm verwenden, um die Kontextwechsel vollständig im Benutzerbereich durchzuführen, und theoretisch eine bessere Leistung erbringen als Threads auf Kernelebene, aber die Leistung würde sofort wieder aus dem Fenster fliegen Sie führen IO ein, da ein Thread, der IO ausführen soll, zuerst teure Tests durchführen müsste, um zu prüfen, ob die Operation blockiert, und wenn dies der Fall ist, die Kontrolle an einen anderen Thread zu übergeben.

Ich bleibe bei meiner Position, dass „grüne Fäden“ eine Idee sind, deren Zeit lange vorbei ist. Dies scheint auch die Position der Austin Group (verantwortlich für POSIX) zu sein, die die entfernt hat ucontext Funktionen in POSIX 2008 und empfohlener Ersatz durch POSIX-Threads (die jetzt ein obligatorisches Feature sind).