- A hozzászóláshoz be kell jelentkezni
- 1632 megtekintés
Hozzászólások
A UNIX 03 nem szabvány, hanem tanusítvány. A hozzá kapcsolódó szabvány az a Single UNIX Specification 3. A SUS pedig már régóta a POSIX helyébe lépett. Egyébként korrekt a hír.
- A hozzászóláshoz be kell jelentkezni
IMHO:
A Single UNIX Specification 3 egy szabványcsalád összefoglaló neve. A UNIX 03 egy "product standard" (amit nem tudok máshogy lefordítani, mint "termék szabvány"), amely része a SUS 3-nak. Nyilván, ha megfelelsz a UNIX 03 Product Standard-nak, akkor megkapod a UNIX 03 tanusítványt.
"UNIX 03 is the latest UNIX Product Standard developed by the Open Group Platform Forum for the Single UNIX Specification version 3."
"The UNIX 03 Product Standard is built out of the following subsidiary Product Standards:
* Internationalized System Calls and Libraries Extended V3
* Commands and Utilities V4
* C Language V2
* Internationalized Terminal Interfaces"
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
És a strnlen(3) már jól működik az 5.3-ban?
- A hozzászóláshoz be kell jelentkezni
util-linux.c nevű komponens a következő szépséggel örvendeztetett meg:
#ifndef HAVE_STRNLEN
size_t strnlen(const char *s, size_t maxlen)
{
int i;
for (i = 0; i < maxlen; i++) {
if (s[i] == '\0')
return i + 1;
}
return maxlen;
}
#endif
Tehát pl strnlen ("", 1024) az szerinte 1. Hát bizonyára.
- A hozzászóláshoz be kell jelentkezni
Ha már csak így fórumozol magaddal 12 év távlatából... ;)
Ez bizonyára egy hiba, így az AIX nem linux kompatibilis.
Az strnlen() meg nem POSIX kompatibilis.
A fenti függvény nem csak rossz, de elavult is.
A későbbi verziókba meg belerakták, minden bizonnyal jól működik.
Nem nagy ügy.
- A hozzászóláshoz be kell jelentkezni
Bocsi, nem írtam a részleteket, ez az util-linux nem az AIX része; azért van benne strnlen, hogy azokon a platformokon is menjen, ahol nincs strnlen. Ez nagyon rendes dolog lenne tőlük (még ha ritkán/soha lenne is rá szükség), ha nem hibás volna ez a strnlen-implementáció...
- A hozzászóláshoz be kell jelentkezni
Ezt értettem az elsőre is. :)
De elég jót szóltál: még ha ritkán/soha lenne is rá szükség
Itt egy hibátalan implementáció. Ez egy első találat, de AIX-re is így írtam volna meg. Pl. az AIX 7.1-ben már van ilyen.
Bennem teljesen más kérdés merült fel. Az ilyenek szerintem általában kényelmi (?) függvények. Rengeteg szöveget feldolgozó programot írtam, de egyszer sem használtam a string.h-t. (wchar meg nem volt). A kérdés - gondold végig: Vajon hogyan áll elő olyan input, amit ezzel a függvénnyel kell vizsgálni? Saját szavaimmal: Bejött-e egy olyan string, ami belefért a bufferbe? Ilyet legfeljebb az fgets() tud előállítani, de ott meg pont az az érdekes, hogy van-e 0 a végén. Ennek a vizsgálatára meg pont elegendő a memchr(). Mint ahogy a forrás is mutatja. :-)
Kár a libct-t terhelni az ilyenekkel, inkább makró kategória.
- A hozzászóláshoz be kell jelentkezni
Ezek is nagyon érdekes kérdések, de ha már így beszélgetünk, megemlíthetjük azt is, hogy honnan kezdődött ez a probléma: https://stackoverflow.com/questions/50541353/flock-command-in-aix
Valamennyire lefordítottam a derék flock-ot, de a 'script-friendly' működés garantáltan nem fog összejönni, mert az AIX-on a szülő- és gyermekprocesszek nem osztják meg a fájl-lokkokat.
Szerk: azért haladunk
https://github.com/karelzak/util-linux/issues/643
https://stackoverflow.com/questions/50541353/flock-command-in-aix/50561…
- A hozzászóláshoz be kell jelentkezni
No, itt a lelkembe gázoltál.
Írtam úgy 24 éve egy (hard)lock mechanizmust ami lényegében exkluzív odataccsol egy fájlt. (Keith Haviland - Ben Salama: UNIX SYSTEM PROGRAMMING, 1987) Ez kisebb terhelésekre, 0 hosszúságú fájlokra (jfs? vagy ext4) tökéletes. Aztán készült egy olyan script linuxra, ami kissé kinőtte magát: Kevesebb, mint 60M processzt futtat naponta és ezen belül/kívül (c utilból hívva) kb. 20M lockra van szükség. Gyorsításként megcsináltam a touch -> flock átalakítást a c és a shell kódban is. Egyes esetekben az flock (script util) "szalajt"!
Bzonyítás. ;)
- Ha az flock nem működne, akkor az egész rendszer szétzilálódna.
- Viszont egy-egy helyen kénytelen voltam a régi "hard lockot" visszacserélni, mert egyértelműen nem működik. Ráadásul nem valami bonyolult konstellációban.
- Van egy függvény pár, az egyik berak valamit egy queue-ba, a másik kivesz. Szempontunkból a két függvény jóformán semmit sem csinál, elfér egy képernyőn, és precízen körbe van kerítve a lokkokkal. Szóval nincs itt semmi látnivaló, de néha téveszt. A hard lockra visszacserélve nem téveszt.
Magyarázat nincs. Legfeljebb írok egy saját lock mechanizmust.
AIX-on a szülő- és gyermekprocesszek nem osztják meg a fájl-lokkokat.
Ez így nem teljesen igaz. Ezt írják: Locks are not inherited. Therefore, a child process cannot unlock a file locked by the parent process.
A jelenség kikerülhető a (pszeudokód!) következő módon:
flock(LOCK)
fork()
flock(UNLOCK)Hasonlót javasol a linux flock(1) példája is, amikor csak az flock{command} >>PIDFILE szerkezetet javasolja. Itt a "command" bármi lehet.
- A hozzászóláshoz be kell jelentkezni
Ezek szerint ezt egy kicsit elnagyoltam, Linuxon ilyesmi megy:
parent: handle= open("lockfile")
parent: fork
child: flock (handle)
child: exit
parent: ...
parent: ... tesz-vesz, az flock érvényes,
parent: ... amíg be nem zárja 'handle'-t, vagy ki nem lép
parent: exit
A 'parent' itt egy shell-script lehet, 'child' pedig a /usr/bin/flock, a manual-ban lévő utolsó példa írja le ezt a használatot.
- A hozzászóláshoz be kell jelentkezni
Így jár, aki ebben a korban fejből idéz valamit. :(
Szóval összemostam a man-t, meg amit csinálok. Egerezve:
DBCACHELOCK=$CONFIGDIR/db.cache.lock # ez az open lockfile
DBCACHELOCKFD=1023
eval "exec $DBCACHELOCKFD>&-"
eval "exec $DBCACHELOCKFD>>$DBCACHELOCK"
...
FLOCK=/usr/bin/flock
...
# sok forkkal és függvénnyel később
...
$FLOCK -x $DBCACHELOCKFD
# ... commands executed under lock ...
$FLOCK -u $DBCACHELOCKFDA fenti programrészlet működik több ágban, de a child-ra nézve mindig azonos szinten van.
A "commands executed under lock" a védett kód.
- A hozzászóláshoz be kell jelentkezni