SPECS: gimp.spec - added missing png, makefile patch (to install t...
Jakub Bogusz
qboosh w pld-linux.org
Nie, 26 Gru 2004, 18:01:26 CET
On Sun, Dec 26, 2004 at 03:56:59PM +0100, Fryderyk Dziarmagowski wrote:
> On Thu, 23 Dec 2004 22:16:11 +0100
> Jakub Bogusz <qboosh w pld-linux.org> 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?
Dobrze, że zwróciłeś uwagę na zepsuty pakiet.
$ 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)
Ładne mi "where available"... :/
(inna rzecz, że przy podmontowanym /dev/shm się często (p~0.3) wykłada
się przy starcie z SIGFPE...)
> 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.
google nie znalazły, żeby gdzieś było używane --with-shm=posix w gimpie
z wyjątkiem MacOS X (gdzie, wg komentarza w configure, SysV shm jest
zepsute). Na innych systemach SysV jest domyślne.
gimp budowany z --with-shm=posix nadal używa SysV shm do innych celów
(nie wiem gdzie, w gtk+2, pythonie? w każdym razie ipcs to ujawnia):
-rw------- 1 qboosh qboosh 16384 2004-12-26 17:24 /dev/shm/gimp-shm-15937
------ Shared Memory Creator/Last-op --------
shmid owner cpid lpid
119111680 qboosh 15937 15939
119144449 qboosh 15937 15939
--
Jakub Bogusz http://cyber.cs.net.pl/~qboosh/
Więcej informacji o liście dyskusyjnej pld-devel-pl