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

XCHAOS: ne každý pracuje na nudných firemních projektech za peníze - jen tak pro zajimavost, "firemni projekt za penize" pro tebe implikuje "nudny projekt"?

že je víc cool se všem ostatním posmívat, že používají C k něčemu, k čemu nebylo určen - ale kdeze. Neposmivam se ti proto ze pouzivas C k necemu, k cemu neni urceno. Neposmivam se ti dokonce ani proto, ze do zdi na konci tehle slepe ulicky busis hlavou uz mnoho let, navic dokonce v situaci kdy sam v podstate uznavas ze to je slepa ulicka. Castecne se ti posmivam proto, ze si nenechas poradit (a tim nemyslim nutne ode me, ale prakticky od vsech ostatnich pritomnych). Hlavne se ti ale posmivam proto, ze navzdory tomu vsemu mas takovou absenci soudnosti, ze tohle vsechno vydavas za dukaz svoji kreativity a zaroven omezenosti ostatnich. Ale tak je to je vsech nasich sporech, ze ano.

REDGUY: tak je to tak trochu klub pro lidi, kteří chtějí někde prezentovat, na čem dělají a tak... ne každý pracuje na nudných firemních projektech za peníze - jsou i lidi, co programují spíš pro sebe, jako hobby, a pak se o tom chtějí někde bavit...

chápu, že je víc cool se všem ostatním posmívat, že používají C k něčemu, k čemu nebylo určené, a že všechno, co dělají, je zbytečné. ale to můžeš dělat někde jinde....

ADAMJ: jo, no já už si přečetl celou tu myšlenkovou linii, no jo. no v éře DOSu ještě dost lidí programovalo v assembleru, to je fakt. já ne.

XCHAOS: Tak treba ... lemme think ... hmm ... v cecku? :D

XCHAOS: tak jediný řešení, jak udržet debatu ontopic, by bylo zabanovat id REDGUY Yup, je to moje vina. To ja sem pisu veleskromne off-topic ody na vlastni kreativitu jako treba [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] ... hmm... moment. To vlastne neni moje zprava. Hmmmm. To nechapu. Ale aspon ze mam posledni slovo! 8))

BLAMI: tak jediný řešení, jak udržet debatu ontopic, by bylo zabanovat id REDGUY, který prostě musí mít poslední slovo.

jinak opravdu nevím, kdy "nepřipouštím vlastní neznalost"... ano připouštím, že nehodlám C používat k psaní driverů do kernelu (ale určitě by bylo ontopic, kdyby to tu někdo chtěl diskutovat! i když jak název napovídá, tak je klub zaměřený primárně na userspace aplikace napsané v C)