- Gurulunk, WAZE?!
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- eBay-es kütyük kis pénzért
- user2: Kia Ceed Gold 160 1.5 T-GDI MY2024
- Argos: Szeretem az ecetfát
- Brogyi: CTEK akkumulátor töltő és másolatai
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
-
LOGOUT
Új hozzászólás Aktív témák
-
pmonitor
aktív tag
válasz
jattila48
#16450
üzenetére
Igen. Pl. itt a FindFileC.exe-t pontosan így készítettem(goto egy sincs benne
). Tehát van a TC, a FindFile és a FindFileC. A TC a leglassabb. A másik kettő sebessége megfelelő(kb. egyforma). Mondjuk hozzá kell tennem, hogy a C#-os FindFile.exe-t is C stílusban írtam(az OOP alapelveit felrúgva). Viszont mióta a C-ben készült változat megvan, azóta azt használom, mert egyrészt 2 kilóval rövidebb a C#-osnál(azért ez 10 kiló körüli programnál jelentős eltérés), másrészt nem kell hozzá .Net. Ja, és a C-ben írt vátozatnál van "Tallózás...", és így is kisebb a mérete.A kis mérettel lapcsolatban meg itt van egy 29 byte-os "Hello world!!!" program.
-
opr
nagyúr
válasz
jattila48
#16449
üzenetére
Olvasd el azt is, ami elotte van...
"Ha valamilyen geppel probalsz mondjuk soros porton kommunikalni"Magyarul:
Talakoztam mar olyan kinai fostalicska cuccal, amivel soros porton kellett kommunikalni, es aminek a dokumentacioja chart irt, de valojaban 16 bitet ertett alatta. De nem is wchar volt. Oruletbe kergetett, mire rajottem, hogy gyakorlatilag ugy kell kezelni, hogy minden ertelmes char utan odab@szok meg egy ureset, es akkor fog rendesen mukodni. Na ERRE mondtam azt, hogy a char az char, mindig 8 bit, minden szartol fuggetlenul, csak nehany nagyon specialis esetben van olyan, hogy egy-egy eszkoz mashogy kezeli. Attol meg 1 byte az 8 bit mindenben, es egy char az 1 byte mindenhol, sehol nem irtam olyat, hogy nem.Amugy a tippem az, hogy eredetileg wchar volt, hogy mukodjon az azsiai karakterekkel (azert erre tippelek, mert az inicializalo parancsban kotelezo volt kommunikacios nyelvet megadni - angol, mandarin, 2 byte-ban), aztan a nem kinai implementaciot is arra epitettek, csak uber tre modon, a dokumentacioba meg persze errol basztak irni barmit. Tehat a char az char volt, 8 bit, mint mindig, csak eppen megse, mert ahhoz, hogy a gep felfogjon barmit es ne hulyeseget csinaljon, minden charhoz kettot kellett atkuldeni.
-
martonx
veterán
-
martonx
veterán
válasz
jattila48
#13025
üzenetére
Van értelme ezen ennyit vergődni? Tényleg van olyan file-od, ami setting és folyamatosan változni is fognak a beállítások? És ha tényleg van ilyen, akkor nem egyszerűbb adatbázisban tartani?
Illetve a .Net világában a settings file-ok változásának lekövetését file watcherekkel szokták megoldani, azaz amikor a file watcher bejelez, hogy megváltozott a file, akkor ismét kiolvasod, amit ki akarsz olvasni, és kész.
-
bambano
titán
válasz
jattila48
#13025
üzenetére
linuxon ott az inode. mivel van inode-od, egy fájlt akkor is el tudsz olvasni, ha azután, hogy megnyitottad, letörölték. a linux azt csinálja, hogy számolja a referenciákat az inode-ra, és amikor az lemegy nullára, törli a fájl tartalmát. a könyvtárbejegyzés és a megnyitott file handlere is referencia.
az átnevezés meg annyi, hogy az egyik könyvtárbejegyzésből kinézi, hogy melyik inode-ra mutat, és beleírja a másikba. egyszerűen felülírja a másikban az inode azonosítót. ezért atomi, mert vagy az előző tartalmat tudja egy másik processz beolvasni, vagy az újat, köztes állapot nincs.
-
bambano
titán
válasz
jattila48
#13018
üzenetére
de akkor rossz helyen keresgélsz, mert a rename lehet atomi művelet, de a rename + create biztosan nem lesz egyetlen oprendszeren sem az.
ha neked az a feladatod, hogy létrehoztad egy temporális fájlban az új tartalmat, amit a helyettesítendő fájl helyére kell tenni, azt linuxon lehet atomi műveletként csinálni, a temporális fájlt átnevezed az eredetire. tehát nem azzal kell foglalkozni, hogy eltakarítsd a régit, hanem azzal, hogy az újat oda tedd a helyére. a régit majd eltakarítja a kernel.
rossz megoldás pszeudokódban:
move file file.backup
move file.new file vagy rename file.new filejó megoldás pszeudokódban:
move file.new file -
dqdb
nagyúr
válasz
jattila48
#13019
üzenetére
Erre a célra szerencsésebb lenne a FindFirstChangeNotification használata FILE_NOTIFY_CHANGE_LAST_WRITE filterrel, és a többi folyamat érzékelné a fájl változását a változást követően, nem kellene aktívan monitorozni a fájl tartalmát, töredékére esne az elérési ütközések száma. Ezután a többi folyamat FILE_SHARE_READ sharing flaggel nyitná meg a fájlt (azaz amíg nyitva tartja, addig a fő folyamat nem tudná módosítani azt. nem lesz dirty read), ha nem sikerül, akkor pár tizedmásodperccel később újra próbálkozik. Ha a fő folyamatnál nem sikerül a ReplaceFile hívás, akkor az is pár tizedmásodperccel később újra próbálkozik.
Szerintem érdemes lenne a mostani konfigurációs fájlnak nevezett dolgot kettéválasztása szigorúan konfigurációs fájlra, ami nem módosulna és állapotfájlra, amit a fő folyamat módosítana. Vagy bármi más megoldás (pipe, socket, zeromq, MSMQ, stb.), ahol a fő folyamat értesítené a többi folyamatot, hogy itt van új állapotadat, tessék azt használni.
-
dqdb
nagyúr
válasz
jattila48
#13015
üzenetére
előfurdulhat-e a ReplaceFile végrehajtása közben, hogy a helyettesítendő file név pillanatnyilag nem létezik (mert temporálisra lett átnevezve), miközben egy másik thread próbálja megnyitni
Igen, előfordulhat. És az is, hogy a fő szálon azért száll el a ReplaceFile hívás, mert egy másik szál FILE_SHARE_DELETE flag nélkül nyitotta meg a fájlt és még nyitva tartja.De mindkét eset könnyen érzékelhető és kezelhető a fő és/vagy a többi szál kódjának módosításával.
Ha IPC-re használsz ilyen módon fájlokat, akkor továbbra is azt tartom, hogy a megoldást kellene átdolgozni olyanra, ami nem igényel atomi műveleteket. Vagy ha nem szükséges az üzenetek perzisztens tárolása arra az esetre, ha a többi szál nem futna, akkor a fájlok használatától is teljesen el lehet tekinteni.
bambano: windowst nem ismerem. truncate-nek szokták hívni angolul.
Vagy TRUNCATE_EXISTING paraméterrel kell meghívni a CreateFile-t (ez csak akkor működik, ha már létezik a fájl), vagy CREATE_ALWAYS paraméterrel, és ez vagy létrehozza az új fájlt, vagy truncate-eli a már létező fájlt. -
bambano
titán
válasz
jattila48
#13015
üzenetére
ha az a problémád, hogy lesz olyan pillanat, amikor a fájl nem létezik, ezért nem nyitható meg, akkor ne rename-mel meg mozgatással dolgozz, hanem csonkold.
linuxon ez úgy működne, hogy kimásolod a tartalmát, majd belemásolsz egy fájl vége karaktert az elejébe, ettől levágja az egészet. windowst nem ismerem. truncate-nek szokták hívni angolul. -
dqdb
nagyúr
válasz
jattila48
#13011
üzenetére
A Windows ReplaceFile API függvényével kapcsolatban érdekelne, hogy az mennyiben tekinthető atomi műveletnek.
Ha átadsz backup fájlnevet, akkor a hívó szempontjából közel atominak tekinthető. A közel szó arra vonatkozik, hogy az eredeti fájl tartalma megmarad, csak az attribútumai nem (részletek itt).A kérdésem az, hogy a Windows preemptív ütemezője átadhatja-e a vezérlést másik thread-nek/processznek a ReplaceFile végrehajtása közben.
Természetesen. És mivel jellemzően egyetlen szálnál több létezik manapság egy processzorban, így még a preemptív végrehajtásfelfüggesztés sem kell ahhoz, hogy párhuzamosan más is fusson.Mert az, hogy a ReplaceFile teljesen vagy egyáltalán nem hajtódik végre, rendben van, de előfordulhat-e, hogy a ReplaceFile véhrehajtása közben egy másik thread megpróbálja megnyitni a helyettesítendő file-t?
Előfordulhat.Ekkor ugyanis lehet, hogy a másik thread nem fogja tudni megnyitni a file-t.
Ha olyan sharing flagekkel nyitja meg, amit a ReplaceFile nem enged, akkor nem fog sikerülni, ha olyannal, hogy engedi, akkor igen.Ha a ReplaceFile olyan értelemben lenne atomi, hogy az ütemező közben nem adhatná át a vezérlést másik thread-nek, akkor ez a probléma nem léphetne fel.
Vagyis egy ReplaceFile hívás blokkolná a teljes operációs rendszert arra az időre, ami nyilvánvalóan nagyon nem jó.TxF kell neked, és ott a MoveFileTransacted hívást, aminél minden fél számára atomi művelet a mozgatás. Vagy gondold át a választott megoldást, mert a legtöbb esetben más működést választva eliminálhatóak azok az esetek, amelyekre most választ keresel.
-
McSzaby
őstag
válasz
jattila48
#8935
üzenetére
(#8937) jattila48:
A többi része már megoldott fejben.Igazából nekem 2-2,5 hónapom van erre, szóval ja...
Rengeteg a nyitott kérdés, szóval egyelőre ez az egész kérdés, amit feltettem csak elméleti síkon mozog. Lehet PERL-ben írom meg, mert abban jóval több tapasztalatom van. Ott egy démon leprogramozása, socket nyitás "szinte" már csuklóból megy. De alapvetően egy TCP kommunikációt én sem találok nehéz feladatnak. Persze, itt azért a bonyolultsága nagy kérdés.
A probléma az itt, hogy megkötik a kezem és emellett szinte semmi segítséget nem kapok. Ezért kell egy hülye biztos, moduláris, céges platform független fost alkotnom és igen, elnézést a kifejezésért, de ebből csak fos lesz, mert én sysadmin vagyok, nem programozó.
Rengeteg a piacon fellelhető toolt kellett már a cégnél lefejlesztenem és nem értem miért nem lehet ELK Stack-t, Nagiost, Puppet-t, Chef-t használni.
Szóval, nagyon szépen köszönöm a segítségeket, véleményeket, ezeket mind meg fogom fontolni és eszerint döntök!
Nagyon köszönöm!
-
Karma
félisten
válasz
jattila48
#8935
üzenetére
TCP kapcsolatot megírni valóban gyerekjáték, kb. bármelyik nyelven, de messze eltörpül a tényleges feladat mellett. Tényleg jelentéktelen. Ha házi megoldás kell, akkor se ez az az idióma amivel el lehet indulni értelmesen egy ekkora kliensszám és a fejekben élő stabilitási kritériumok mellett.
Az eredeti kérdés politikai vonzatára visszatérve: egy házi barkács megoldásnak semmilyen supportja nincs, csak addig az ideig-óráig, amíg foglalkozik vele a barkácsoló fejlesztő. Rá egy hónappal már teljesen esélytelen. Nem tudom milyen vezetés az, aki ezzel még nem égette meg magát, de sajnos valóban előfordul ez az ultrarövidtávú szemlélet...
-
McSzaby
őstag
válasz
jattila48
#8927
üzenetére
Szia,
kb. 150-200 kliensről van szó.Titkosításra nem lesz szükség szerintem, a hálózati csomópontok, illetve egyebek elég jól védettek a hálózaton. Ha valaki már odáig eljut, hogy itt hálózati forgalmat tudjon nézni, akkor már rég mindegy a történet.
Tudom, hogy google a barátom, de nem tudnál/tudnátok esetleg adni valamilyen leírást, "howto"-t, ahol az ilyen témát taglalják és vehetem referenciának?
). Tehát van a TC, a FindFile és a FindFileC. A TC a leglassabb. A másik kettő sebessége megfelelő(kb. egyforma). Mondjuk hozzá kell tennem, hogy a C#-os FindFile.exe-t is C stílusban írtam(az OOP alapelveit felrúgva). Viszont mióta a C-ben készült változat megvan, azóta azt használom, mert egyrészt 2 kilóval rövidebb a C#-osnál(azért ez 10 kiló körüli programnál jelentős eltérés), másrészt nem kell hozzá .Net. Ja, és a C-ben írt vátozatnál van "Tallózás...", és így is kisebb a mérete.
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
- Nintendo Switch 2
- Gurulunk, WAZE?!
- Atomenergiával dübörögnek tovább az Amazon adatközpontok, SMR-ek is jöhetnek
- Kerékpárosok, bringások ide!
- OTP Bank topic
- Milyen széket vegyek?
- Debrecen és környéke adok-veszek-beszélgetek
- Kerékpársportok
- Álláskeresés, interjú, önéletrajz
- CASIO órák kedvelők topicja!
- További aktív témák...
- ÚJ PS5 Slim - FW 8.40 - Lemezolvasó - Lua Loader - Lua játék - Lapse
- új, bontatlan, iPhone 16E gyárilag kártya-független, apple világgaranciával
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 1TB SSD Radeon Pro 5500M
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 2TB SSD Radeon Pro 5600M 8GB
- MacBook Pro 14" M1 MAX - 32GB / 1TB (2021) - 1 év garancia
- AKCIÓ! Apple Macbook Pro 16" 2019 i9 9980HK 64GB 500GB Radeon Pro 5500M hibátlan működéssel
- ASUS TUF Gaming F16 FX607JV-QT212 Notebook
- AKCIÓ! GIGABYTE GA-Z170X-UD3 Z170 chipset alaplap garanciával hibátlan működéssel
- Országosan a legjobb BANKMENTES részletfizetési konstrukció! Lenovo ThinkPad X13 Gen 5
- Bomba ár! Lenovo X1 Yoga 1st - i7-6G I 8GB I 256SSD I 14" WQHD Sérült I W10 I CAM I Garancia!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged