Re: Počet vláken

Radek Sztwiorok sztrad na gmail.com
Čtvrtek Prosinec 10 12:31:57 CET 2020


Dojdou ale pozdeji.:-)
Kouknete ve spravci programu jestli vam pomalu neroste potřebná pamet u
bezici aplikace

čt 10. 12. 2020 v 12:25 odesílatel Martin Záruba <swz na volny.cz> napsal:

> Hurá, už to funguje. Ta odpověď byla opravdu na
> https://forum.lazarus.freepascal.org/index.php?topic=26441.0
> <https://forum.lazarus.freepascal.org/index.php?topic=26441.0>
>
> Jde o ten limit 2 GB. Když se to podělí defaultní hodnotou 16 MB na
> vlákno, dojde počet vláken. Jenže já naprosto nepotřebuji 16 MB. Ve
> Volby projektu, Generování kódu, Velikost zásobníku -Cs jsem dal 524288,
> tedy 0,5MB a vlákna nedojdou.
>
> Moc děkuji
>
> Martin Záruba
>
> Dne 10.12.2020 v 12:11 Radek Sztwiorok napsal(a):
> > Ten pocet problem nebude.
> > Mne tu aktualne bezi  do diagnostiky napsane v lazarusu na modbusu 236
> > zarizeni a nekope se to. Tam bude nekde chybka v programu.
> >
> > čt 10. 12. 2020 v 11:59 odesílatel Marek Sembol <hwm.land na gmail.com
> > <mailto:hwm.land na gmail.com>> napsal:
> >
> >     Jak rikam - Lazarusi detaily neznam, ale sockety
> >     podporuji non-blocking operace snad 'odjakziva' - a presne tak se
> >     to taky v servrech resi.
> >     Pravda - v dnesni dobe uz je to lepe zabaleno, takze v .NET pred
> >     4.0 to byly pary metod BeginNeco/EndNeco, od 4.0 jeste
> >     jednoduzsi pouziti pomoci NecoAsync
> >     Verim tomu, ze Lazarus bude mit taky podporu
> >
> >     PS: rozumim tomu spravne, ze vam tam komunikuje 120+ PLC?
> >     BR,
> >     Marek
> >
> >     On Thu, Dec 10, 2020 at 11:25 AM Martin Záruba <swz na volny.cz
> >     <mailto:swz na volny.cz>> wrote:
> >
> >         No já to vlastně takto předělal z verze, kdy bylo jedno
> >         vlákno. Ono to v
> >         podstatě funguje tak, že se připojí klient (PLC). Server
> >         vyhodnotí, že
> >         je to oprávněné připojení a pak se již stará o komunikaci. Tím
> >         pádem PLC
> >         může být za firewallem a nemusí mít veřejnou IP. Problém je v
> >         tom, že
> >         komunikace běží na pomalém modbusu, takže naprostá většina
> >         doby je
> >         čekání na data. Pokud to jsou vlákna, tak to není problém,
> >         protože se o
> >         to stará systém a i na prastarém procesoru je vytížení
> >         zanedbatelné.
> >         Jenže nedovedu si představit, jak se jedno vlákno bude starat o
> >         komunikaci s několika zcela asynchronně běžícími procesy.
> >
> >         Jinak tak, jak jste to popsal to funguje, jenže jekmile
> >         naslouchací
> >         vlákno identifikuje požadavek a spustí to komunikační, dál se
> >         o to
> >         nestará. To je mi jasné, jenže to komunikační vlákno vlastně
> >         nikdy
> >         nekončí, protože je to smyčka, která čte data (nebo i
> >         zapisuje) z PLC
> >         tak rychle, jak to modbus zvládne. Pokud spojení spadne,
> >         vlákno se
> >         ukončí a PLC se pokusí přihlásit znovu a zase dostane vlákno.
> >         Tak mě
> >         nenapadá, jak to udělat jinak.
> >
> >         Martin Záruba
> >
> >         Dne 10.12.2020 v 7:33 Marek Sembol napsal(a):
> >         > Zdravim,
> >         > Lazara neznam ani omylem, ale: Ono chyba 'out of memory'
> >         nemusi nutne
> >         > znamenat, ze dosla pamet obecne. Mnohdy ma program/system
> >         vyhrazenou
> >         > statickou (pevne delky) tabulku na nejake prostredky pokud
> >         nema volny
> >         > slot - vyhodi out-of-memory (a ma pravdu-dosla mu vyhrazena
> >         pamet) Na
> >         > podobny problem jsem narazil jednou s .NET (tehdy jeste 3.5)
> >         Program
> >         > pomerne intenzivne (az agresivne) vyuzival thready z
> >         ThreadPool.
> >         > Problem byl, ze tam byl taky pevny strop - a jeste zavisly
> >         na poctu
> >         > jader. Tusim 256/jadro.
> >         > Obecna rada - ono stejne neni pro system moc zdrave drzet si
> >         stabilne
> >         > tolik thready. Kazda sranda (thread) neco stoji. Ten thread
> >         dokonce
> >         > relativne dost.
> >         > Takze moje rada vas nepotesi - predelat strukturu programu, aby
> >         > nepotreboval tolik threadu. Neco jako jeden thread na
> >         naslouchani a v
> >         > pripade prichoziho pozadavku, si docasne vytvorit (nejlepe
> >         pouzit z
> >         > thread pool, pokud lazarus ma, jinak si napsat svuj. Tvoreni
> >         thredu je
> >         > hodne drahe) threadik na zpracovani pozadavku a pak ho
> >         zas hezky
> >         > vratit/uklidit.
> >         > BR,
> >         > Marek
> >         >
> >         > On Thu, Dec 10, 2020 at 6:51 AM Martin Záruba <swz na volny.cz
> >         <mailto:swz na volny.cz>
> >         > <mailto:swz na volny.cz <mailto:swz na volny.cz>>> wrote:
> >         >
> >         >     Mám v prostředí Lazarus program, který po připojení přes
> >         TCP/IP
> >         >     založí
> >         >     vlákno a provede příslušnou akci. Pokud ale počet vláken
> >         dosáhne
> >         >     hodnoty
> >         >     115 dostanu zprávu
> >         >
> >         >     Project xxx vyvolal výjímku třídy ´EThread´ se zprávou:
> >         >
> >         >     Thread creation error: K provedení tohoto příkazu není dost
> >         >     paměťových
> >         >     prostředků
> >         >
> >         >
> >         >     Jenže ono to nezáleží na paměti. Na různých PC se to
> >         chová stejně.
> >         >     Zjevně někde přetečou nějaké tabulky. Ale kde?
> >         >
> >         >     --
> >         >
> >         >     Martin Záruba
> >         >
> >         >     _______________________________________________
> >         >     HW-list mailing list  -  sponsored by www.HW.cz
> >         <http://www.HW.cz> <http://www.HW.cz <http://www.HW.cz>>
> >         > Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> >         <mailto:Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>>
> >         > http://list.hw.cz/mailman/listinfo/hw-list
> >         <http://list.hw.cz/mailman/listinfo/hw-list>
> >         >     <http://list.hw.cz/mailman/listinfo/hw-list
> >         <http://list.hw.cz/mailman/listinfo/hw-list>>
> >         >
> >         >
> >         > _______________________________________________
> >         > HW-list mailing list  -  sponsored by www.HW.cz
> >         <http://www.HW.cz>
> >         > Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> >         > http://list.hw.cz/mailman/listinfo/hw-list
> >         <http://list.hw.cz/mailman/listinfo/hw-list>
> >         _______________________________________________
> >         HW-list mailing list  -  sponsored by www.HW.cz <
> http://www.HW.cz>
> >         Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> >         http://list.hw.cz/mailman/listinfo/hw-list
> >         <http://list.hw.cz/mailman/listinfo/hw-list>
> >
> >     _______________________________________________
> >     HW-list mailing list  -  sponsored by www.HW.cz <http://www.HW.cz>
> >     Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> >     http://list.hw.cz/mailman/listinfo/hw-list
> >     <http://list.hw.cz/mailman/listinfo/hw-list>
> >
> >
> > _______________________________________________
> > HW-list mailing list  -  sponsored by www.HW.cz
> > Hw-list na list.hw.cz
> > http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20201210/bb56e9b3/attachment.html>


Další informace o konferenci Hw-list