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