Tja und nu?
Wenn ich in /usr/include/bits/local_lim.h schaue steht da entweder
#define _POSIX_THREAD_THREADS_MAX 64
drin was nicht zur erreichbaren Threadanzahl passt oder aber
#undef PTHREAD_THREADS_MAX
was ich jetzt ja so interpretiert hätte, dass libpthreads kein Thread-Limit kennt - passt also auch nicht.
Thread-Probleme
Damit hängt das ja auch nicht zusammen, PTHREAD_MAX würde EAGAIN hervorrufen. Eigentlich darf pthread_create() auch nur EAGAIN, EINVAL und EPERM zurückliefern, nicht etwa ENOMEM.
Und ignorieren kann man das ENOMEM ja offensichtlich auch, ohne das sofort etwas Schlimmes geschieht. Sehr mysteriös. Aufschluss dürften nur die Quellen der glibc und des Kernels bringen.
Janka
Und ignorieren kann man das ENOMEM ja offensichtlich auch, ohne das sofort etwas Schlimmes geschieht. Sehr mysteriös. Aufschluss dürften nur die Quellen der glibc und des Kernels bringen.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
Hi,
interessehalber habe ich auch mal nach "pthread_create ENOMEM" gegoogelt und dabei ein PDF gefunden, was genau den Fall zu beschreiben scheint: http://www.ipa.go.jp/software/open/foru ... ec-2_e.pdf
Im PDF einfach nach "pthread_create" suchen (S.19, wenn ich mich recht entsinne). Es scheint damit zu tun zu haben, dass für jeden Thread ein eigenes (zu großes) Stack-Segment reserviert wird.
EDIT: Außerdem war da noch ein Link auf http://www.parkes.atnf.csiro.au/observi ... reads.html , der aber auf einen 2.4er-Kernel verweist. Und dieses Posting hier http://www.cygwin.com/ml/glibc-bugs/200 ... 00086.html scheint auf den gleichen Fall zu verweisen, wie er im PDF angesprochen wurde.
Vielleicht hilft's ja weiter,
Jochen
interessehalber habe ich auch mal nach "pthread_create ENOMEM" gegoogelt und dabei ein PDF gefunden, was genau den Fall zu beschreiben scheint: http://www.ipa.go.jp/software/open/foru ... ec-2_e.pdf
Im PDF einfach nach "pthread_create" suchen (S.19, wenn ich mich recht entsinne). Es scheint damit zu tun zu haben, dass für jeden Thread ein eigenes (zu großes) Stack-Segment reserviert wird.
EDIT: Außerdem war da noch ein Link auf http://www.parkes.atnf.csiro.au/observi ... reads.html , der aber auf einen 2.4er-Kernel verweist. Und dieses Posting hier http://www.cygwin.com/ml/glibc-bugs/200 ... 00086.html scheint auf den gleichen Fall zu verweisen, wie er im PDF angesprochen wurde.
Vielleicht hilft's ja weiter,
Jochen
Die grösste Lüge der EDV? "Mal eben..."
Ich hatte mir sowas auch schon gedacht, jeder Thread braucht einen eigenen Stack, klar. Andererseits sollte das ENOMEM natürlich dokumentiert sein, oder es sollte doch lieber EAGAIN zurückgeliefert werden.
Danke fürs Suchen, Jochen.
@WilliWupp: Hilft dir das PDF weiter? ulimit -s 1024 oder ähnlich setzen, danach Programm starten.
Janka
Danke fürs Suchen, Jochen.
@WilliWupp: Hilft dir das PDF weiter? ulimit -s 1024 oder ähnlich setzen, danach Programm starten.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
Hallo,
was bei allen Beispielen fehlt:
das Handle des Threads
das mit
erzeugt wird, muss mit
wieder freigegeben werden.
Gruß Bobbin.
was bei allen Beispielen fehlt:
das Handle des Threads
Code: Select all
pthread_t mStruct;
Code: Select all
pthread_create(mStruct,&attr,func,arg)
Code: Select all
pthread_detach( mStruct );
Gruß Bobbin.