XCHAOS: Sorry, ale to ze musim udelat:
int *foo = alloca(5*sizeof(int));
bar(foo);

misto

bar(alloca(5*sizeof(int)));

Mi az tak omezujici neprijde. Ale pochopitelne, ymmv

DAVIDOWITCH: jo. já teda používám -std=c99 takže mě asi něco z toho trápit nebude... ale spíš mě jde o to "On many systems alloca() cannot be used inside the list of arguments of a function call, because the stack space reserved by alloca() would appear on the stack in the middle of the space for the function arguments. " - to mě přijde jednak logické, jednak jako vážné omezení.

kdybych věděl, jak zjistit kolik mi zbývá místa na stacku, tak můžu zavolat set_rlimit() pokaždé, když by další alokace to místo spotřebovala :-) ale co jsem tam googlil, tak zjistit tohle vůbec není triviální.

můj závěr je, že pro svojí službu bleskové dealokace celého poolu paměti současně nebudu používat alloca() (ani kdyby to náhodou v gcc fungovalo jak očekávám) - i když to automatické uvolnění po návratu z jakékoliv funkce je samozřejmě lákavé.

XCHAOS: http://linux.die.net/man/3/alloca
Myslis to varovani tady?

HARVIE: o to nejde, jestli je to do nekonečna... malloc() má k dispozici v podstatě veškerou momentálně zbývající RAM + velikost swapu k tomu + ještě vypudíš z RAM diskovou cache, než to začne swapovat. velikost stacku je naproti tomu nastavená fixně (a výchozí velikost je zjevně 0.5 MB).

XCHAOS: Mno... Ani mallocovat se neda do nekonecna zejo...

JANFROG: mě v podstatě jde jen o to napsat si nějaký co nejjednodušší memory pool, u kterého budu plně rozumět tomu, jak funguje - a bude schopen jednoduše hromadně uvolňovat větší množství paměti (i bez použití garbage collection).

že to nemusí fungovat mimo scope, ve kterém alokuju, to mě nevadí - to je u mě spíš feature, ne bug, konec funkce či scope je pro mě vhodné místo, kde masivně dealokovat (pokud se s tím od začátku počítá) (ostatně garbage collection pomocí reference counteru by taky dealokovala typicky v místě, kde zanikne poslední reference na objekt, což je v řadě případů to samé místo)

DAVIDOWITCH: no man alloca před tím varuje, tak nevím... podle téhle manuálové stránky se takto alokovaná paměť překrývá ze začátkem stacku z hlediska té volané funkce.

XCHAOS: Hmm.. ja uz alloca chvili nepouzival a na linuxu nikdy, ale nevybavuju si ze bych mel nejakej velkej problem s predavanim pameti volanym funkcim. V cem je ten problem?

asi se přiznám, co jsem spáchal tentokrát (zvýrazňovátko si do Debianu nainstalujete pomocí apt-get install highlight - bohužel jsem ale nepřišel na to, jak u téhle konverze zabránit zdvojení řádkování :-) )

#include <stdio.h>

#include <alloca.h>

#include <malloc.h>

#include <sys/time.h>

#include <sys/resource.h>



int main(void)

{

 int i;

 char *buf;

 struct rlimit r;



 getrlimit(RLIMIT_STACK,&r);

 printf("RLIMIT_STACK soft=%d, hard=%d\n",r.rlim_cur,r.rlim_max);

 r.rlim_cur=20000000;

 setrlimit(RLIMIT_STACK,&r);

 getrlimit(RLIMIT_STACK,&r);

 printf("RLIMIT_STACK soft=%d, hard=%d\n",r.rlim_cur,r.rlim_max);

 printf("%d\n",time(NULL));

 for(i=0;i<500000;i++)

 {

  buf=alloca(2);

 }

 printf("%d\n",time(NULL));

 for(i=0;i<10000000;i++)

 {

  buf=malloc(2); 

 }

 printf("%d\n",time(NULL));

}

po spuštění to vypíše tohle (cílem bylo mj. zkusit změřit rychlost alokace paměti, která je u malloc() v 64bitovém virtuálním stroji které má přiděleno jedno jádro někdo kolem 10 milionů za sekundu)

RLIMIT_STACK soft=8388608, hard=-1
RLIMIT_STACK soft=20000000, hard=-1
1339660461
1339660461
1339660462


.. takže evidentně s tím stackem lze za chodu hýbat... otázka tedy je, jestli by mělo smysl dělat nějaký wrapper kolem tohoalloca (resp. jak vůbec zjistím, kde momentálně na stacku jsem a jestli si můžu dovolit allocal()).

stejně si myslím, že jsou důvody to nedělat (viz že by pak nešlo alokovanou paměť přímo předávat volaným funkcím...což se sice nedělá často, ale je to podobně matoucí, jako když makro provede dvojí vyhodnocení výrazu předaného jako parametr, apod.)

V podstatě se obloukem vracím k zavržené anketě [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] kde všichni chtějí být hrozně pokročilí: nedá mi to, ale nemyslím si, že k C může jen tak přijít někdo, kdo se naučil programovat na JavaScriptu, PHP nebo Perlu, a jen tak rutinně ho začít používat s tím, že "místo tamtoho se používá tohle, brnkačka".

třeba s tím odchytáváním SIGSEGV... jsem fakt zvědav, co si představujete, že jde dál dělat, když vám dojde místo na stacku: kromě nějakého zalogování chyby či nouzového uložení důležitých a přitom dosud neuložených dat toho podle mě moc dělat nejde. resp. kdyby šlo o chybu malloc(), tak má v multitaskovém prostředí cenu zkusit po nějaké době alokovat paměť znovu.... ale u toho alloc

dobře... ještě je tu volání brk() a sbrk() ... to se přiznám, že je pro mě alchymie :-) hmm....

setrlimit(RLIMIT_STACK,..) ... tím chcete říct, že když se před každým voláním alloca() zeptám, jestli mám dost místa, že můžu stack případně on-demand zvětšit? tak to snad budu muset zkusit :-)

JANFROG: je tam ještě jedno "ale" - já si chtěl napsat "univerzální" alokátor, který se bude používat všude stejně - ale budu nad ním mít nějaké řídící nástroje (v mém případě flow control makra, ale lze si to představit i "čistší", jako volání nějakých přepínačů), které by řekly, kam se alokuje. no ale protože alloca() je v gccv inlinované, tak to není funkce, na kterou by šlo získat pointer.... a stejně tak to nejde obalit funkcí, právě proto, že to alokuje na stack.

DAVIDOWITCH: asi ano, ale těch nevýhod je tam více - např. nemůžeš paměť kterou ti alloca() vrátí jednoduše předat v seznamu argumentů volané funkce, čímž se to přesně blíží omezením, za které tady byla krizována moje makra: prostě pro kohokoliv mimo naprostých guru (kteří přesně chápou jak to je v C se stackem... což i mě pár let trvalo) tam čekají obrovské nástrahy.

XCHAOS: Tak to vychazi z principu alloca(). Vzdycky muzes SEGV chytit, zjistit ze to bylo kvuli tomuhle, zamest pod stul a vratit chybu. Kdyz to budes delat, dej si tam par desitek bytu jako rezervu pro operacni stack handleru te chyby :-)

JACHYMKO: otazka - proc zrovna make? to je jako kdyby si na to chtel pouzit msbuild - pujde to, ale nejak mi neni jasny, co ziskas pouzitim maku proti skriptu v cemkoliv jinym

XCHAOS: Predpokladam ze nejak umis zjistit kolik ti zbejva na stacku a muzes tudiz alloca obalit.
Holt kouzlo alloca je v tom, ze je to fakt superlightweight.

JACHYMKO: buď cp -r a nebo, pokud jsi náročnější, tak si přečti man install. (ale já se přiznám, že jsem ten typ linuxáka, co nedá ani ránu bez Midnight Commanderu :-)

tak jsem si zaexperimentoval... a na stacku (u programu nastaveného s implicitním nastavením compileru) nelze alockovat ani 50000x 2 bajty (1 mega) - a ani žádnou chybovou hodnotu to nevrátí, prostě rovnou Neoprávněný přístup do paměti (SIGSEGV). (jo, jistě si jde velikost stacku nějak poručit... o tom nepochybuju...)

takže alloca() zavrženo. znovu na začátek: potřebuju něco, co by se chovalo podobně jednoduše (hromadné uvolnění paměti), ale bylo by to poněkud "slušněji vychované".

tak jsem přemýšlel jak se postavit k ty svý alokaci paměti... a zrovna když už jsem si říkal, že se na to vykašlu a budu místo svých memory poolů ve většině případů používat prostě alokaci na stacku - alloca() - tak jsem si pořádně přečetl manuálovou stránku, co k tomu patří, a zase si to rozmyslel.

ach jo.

REDGUY: moderátor občas musí holt poněkud offtopic komentovat počíná ostatních... je blbý, když si nějaký klub vybere někdo, kdo má nutkání komentovat jakékoliv počínání moderátora a jinak se k tématu vyjádřuje minimálně.

máš 3 dny R/O... ostatní toho snad místo unbookování využijí k tomu, aby se vrátili k tématu.

XCHAOS: a další tvůj příspěvek co je nejen offtopic, ale dokonce i naprosto neinformativní. - odpovidam na tvoji zpravu. Pokud je ontopic tvoje povidani o tom, jak je cool se ostatnim vyspivat, je ontopic i moje odpoved. Pokud ontopic neni tvoje zprava na kterou jsem reagoval, tak jen pokrytecky vycitas ostatnim co sam delas. A radsi nebudu resit jak "ontopic" je primo tahle tvoje zprava, vid 8))