A hle, stejne jako Zombie Jesus, po trech dnech vstavam z banu a jsem zpet 8)

Nejdriv troska offtopic, coz?
XCHAOS: moderátor občas musí holt poněkud offtopic komentovat počíná ostatních Coz by bylo dobre zduvodneni, kdyby ty tvoje off-topic prispevky byly skutecne moderovani, a nikoliv mentalni masturbace nad vlastni kreativitou, nesmyslne obvinovani oponenta z chybne argumentace, podsouvani oponentovi neceho, co nikdy nerekl nebo blaboleni o smyslu zivota Kdybys skutecne jen moderoval, tak ano, mas pravdu. Coz jsi ovsem nedelal. A pokud off-topicujes uplne stejne jako ja, tak kdyz potom vytahnes moderatoske kladivo, je to proste jen zbabelost (a rekneme "neuprimnost", pokud to vydavas za moderovani). Jen tak do zaznamu 8)

No, ted ale neco k veci, coz?

Zakladni vec ktera v cele tehle dbate chybi, je kdyz uz ne analyza, tak aspon zduvodneni:

- Pro koho ma byt xallokator urcen?
- Pro co je to urceno?
- Ma to byt nahrada nebo doplnek stavajicich zpusobu alokace pameti?
- V cem jsou soucasne zpusoby alokace pameti nedostacne a proc?
- V cem (a jak moc) chces byt lepsi?
- Jak dobre to ma fungovat s jinejma knihovnama?
- Jak to celkove koncepcne zapadne do celeho jazyka?

Chapu ze kdyz si takhle aspon trochu nadefinujeme co vlastne delame, tak se pozdeji bude mnohem hur vyhybat pripadnym namitkam pomoci ukroku stranou, ale toho uz jsme si driv uzili dost, ne?


XCHAOS: "tradiční" stringovou gymnastiku v C (ta je prováděna na stacku, tradičně vázaná na nějaké to "MAXLEN" - ne, neni. Ze to tak delas ty neznamena, ze to je obecna tradice.

A btw, dival ses jak funguje alokace pameti v Objective C, jak uz jsem ti nekolikrat doporucoval? Docela by me to zajimalo - kdyz mi vycitas off-topic prispevky, rad bych vedel jaky efekt maji ty on-topic 8)

XCHAOS: Ano, co ti chodi zvenku. Uvnitr programu si to zmeris. MAXLEN nepotrebujes.

ANT_39: tak já to chystám přesně jak říkáš - už mám hotovou funkci get_str(), která změří délku všech svých (1 ... n) argumentů, alokuje prostor a nakopíruje do něj obsah stringu (a toto jsem měl mít už dávno a měla by to být podle mě v C norma).

zdrojem řetězců náhodné délky je vše: stringy přicházející z textových konfiguráků, z databáze, z webových formulářů... string známé délky je naprosto speciální případ a mimo chráněný svět zdrojového kódu programů a počítačových her se prakticky nevyskytuje.

Prosím o pomoc, dokázal by někdo z vás zkompilovat toto pod Windows? https://github.com/spekode/sskey, zkoušel jsem CygWin, MinGW, ale nedaří se mi :(

ISTEVE: tak typicky delší životnost než funkce, ve které vznikají, mají "moje" spojové seznamy (viz předchozí flamewar - ale i navzdory argumentům, které zde padly, je to stále moje oblíbená datová struktura...).

typickým příkladem dočasné alokace jsou pak různé operace na bázi immutable stringů (ve stylu Pythonu), které pokládám za bezpečnější, než "tradiční" stringovou gymnastiku v C (ta je prováděna na stacku, tradičně vázaná na nějaké to "MAXLEN" se kterým je alokován každý string)

DAVIDOWITCH: ...pokud nebude funkce brat ownership toho co je ji predano jako argument, treba proto ze ocekava delsi zivotnost tech dat nez caller (ala multithreadovy aplikace)...

...a to s alloca (jak rika janfrog) nemuze vubec, coz je ponekud vetsi omezeni;]

XCHAOS: Tak s mallocem tohle stejne udelat nesmis, protoze si zahodil pointer a nezvladas free, zeano...

DAVIDOWITCH: no tak mě v podstatě ne... ale právě třeba moje makro-zápisy často vedly přesně k něčemu podobnému a byl jsem tady za to dost kritizován...

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.