On Sun, Dec 26, 2004 at 06:43:36PM +0100, Fryderyk Dziarmagowski wrote: > On Sun, 26 Dec 2004 18:01:26 +0100 > Jakub Bogusz <[EMAIL PROTECTED]> wrote: > > > > On Tue, Dec 21, 2004 at 08:30:48PM +0000, freetz wrote: > > > > > Author: freetz Date: Tue Dec 21 20:30:48 > > > > > 2004 GMT Module: SPECS Tag: HEAD > > > > > ---- Log message: > > > > > - added missing png, makefile patch (to install this png), > > > > > rereshed old > > > > > py-compile, enabled posix shm by default, nfy > > > > > > > > Dlaczego akurat posix (i nie bardzo "by default") - daje jakąś > > > > przewagę nad sysv? > > > > > > Mamy już zgodne z POSIX wątki w glibcu. Dlaczego nie mielibyśmy iść > > > dalej w z zgodnośći ze standardami? W jack-audio-connection-kit od > > > dawna mamy obsługę posix shm, nie budziły jak do tej pory > > > kontrowersji. > > > > Bo nikt nie testował? I było mylące "where available" w commit logu > > pluta? > > Ja testowałem. W konfiuracji zalecanej przez autorów jacka, czyli z > posix shm. > > > Dobrze, że zwróciłeś uwagę na zepsuty pakiet. > > Z punktu widzenia dystrybucji jest popsuty. Z punktu widzenia > użytkownika nie.
Jeśli ma niepodmontowane przez administratora /dev/shm to też jest. Komunikat o braku shm jest czytelny tylko dla bardziej zaawansowanych, a ten o SIGSEGV świadczy o błędzie w programie. > > $ jackd -d oss > > jackd 0.99.0 > > Copyright 2001-2003 Paul Davis and others. > > jackd comes with ABSOLUTELY NO WARRANTY > > This is free software, and you are welcome to redistribute it > > under certain conditions; see the file COPYING for details > > > > cannot open existing shm registry segment (Function not implemented) > > Naruszenie ochrony pamięci (core dumped) > > to jest problem afaik z oss, dlatego kiedyś protestowałem, że > wydzieliłeś podstawowy sterownik do podpakietu. Ten nie: $ jackd -d alsa jackd 0.99.0 Copyright 2001-2003 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details cannot open existing shm registry segment (Function not implemented) Naruszenie ochrony pamięci (core dumped) > > Ładne mi "where available"... :/ > > > > (inna rzecz, że przy podmontowanym /dev/shm się często (p~0.3) wykłada > > się przy starcie z SIGFPE...) > > j.w. Ten prawdopodobnie tak. (bt kończy się w jack_oss.so, ale bym musiał zbudować z --debug, żeby zobaczyć) [...] > > Przy aktualnym domyślnym fstabie to jest zmiana na gorsze. > > Dlatego pytam się, jakie korzyści daje POSIX shm w stosunku do SysV > > (oprócz tych 5 liter)? > > Gdyby to było wydajniejsze, można by użyć - ale _po_ uprzedniej > > zmianie domyślnego fstaba. > > Nie jest wydajniejsze. Jest nowocześniejsze i zgodne z POSIX. Z tego co > czytałem nie ma też wiecej wad niż SysV shm, a główną różnicą jest > implementacja. > > jest jakiś istotny powód dlaczego to w PLD jest w gestii administratora, > a nie domyślnie włączone? Ja nie wiem. Od początku (jeszcze z shmfs pod /var/shm) było zakomentowane. Może kwestia rozmiaru (domyślny limit to pół RAM; w przypadku SysV 32MB - to drugie może być nawet bardziej szkodliwe przy <64MB...). -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
