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. > $ 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. > Ł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. > > Gdzie > > widzisz problem, zagrożenie? > > W przypadku jacka właśnie zobaczyłem problem. > W obsłudze błędów i braku fallbacka (do SysV shm czy czegokolwiek). > > > > W domyślnym fstabie /dev/shm jest zakomentowane, bez zmiany tego > > > przez administratora ten default nie będzie działał (tzn. pamięć > > > dzielona nie będzie używana). > > > > Możesz rozszerzyć jakie są negatywne skutki niedziałania defaulta? > > bo aplikacja działa bez problemów w razie braku interwencji > > administracyjnych. > > Wolniejsze działanie - przesyłanie grafiki przez rurkę zamiast shm > (nie ma fallbacka do SysV shm). > > 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? [...] -- Fryderyk Dziarmagowski _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
