[Gelistirici] ÇOMAR ve Servisler (Request for Comments)

[Ozan Çağlayan]

Bahadır Kandemir wrote On 09-01-2008 16:23:
> Selamlar,
>
> Dün servis yönetiminin yeni ÇOMAR'a aktarılması için çalışmalara başladım. 
> ÇOMAR 1.*'daki gibi, tüm servisleri aynı anda paralel olarak başlatmak 
> yerine, servis bağımlılıklarını dikkate alacak bir servis yönetimi 
> oluşturma niyetindeyim.
>
> Planladığım süreç şöyle:
>
> 1) Servis bağımlılık listesini al.
> 2) Bağımlılığı olmayan tüm servisleri paralel çalıştır.
> 3) Başlatma işlemi tamamlanmış her servisin ardından 2'ye dön.
> 4) Servisler başlatıldı.
>
> Bağımlılıkların şu şekilde olduğunu varsayarsak:
>
> dependencies = {
>     'hal': ['consolekit', 'udev'],
>     'consolekit': [],
>     'kdebase': ['hal', 'consolekit'],
>     'apache': ['net'],
>     'mysql': ['net'],
>     'ldap': ['net'],
> }
>
> Servisler bu sırada çalışacak:
>
> * Hepsinden önce dbus
> * [net, udev, consolekit] paralel
> * [net] başlatıldıktan sonra [mysql, apache, ldap] paralel
> * [consolekit] başlatıldıktan sonra [hal]
> * [hal, consolekit] başlatıldıktan sonra [kdebase]
>
> Paralel başlatma işlemi, asenkron çağrılar ile yapılacak. Müdür'de DBus 
> event loop bulunması gerekiyor bu iş için. Glib mainloop kullanırsak 
> Müdür'ün bağımlılıkları arasına pygobject, gtk2, ... gibi bir sürü paket 
> giriyor -ki aynı şey Qt mainloop için de geçerli- olacak iş değil bu.
>
> Bağımlığı olmayan bir DBus çözümü var(dı) depomuzda: D_Light. PyQt4 DBus 
> event loop PyQt3'e port edilemezse diye yazmıştım. Ancak, servis yönetimi 
> gibi önemli bir iş D_Light kullanmak ne kadar doğru emin değilim.
>
> D_Light da olmazsa, paralel servis çalıştırma işini bir kenara bırakıp 
> Müdür öncesi dönemde olduğu gibi her servisi sırayla başlatmaya geri 
> döneceğiz gibi görünüyor.
>
> Siz ne düşünüyorsunuz?
>
> --
> Bahadır Kandemir
>   
Paralel veya seri çalıştırmanın bize getirileri, bizden götürüleri 
neler? Hız açısından ne kadar farkediyor? Açılış sürecinde asenkron 
çağrı+pygobject'ler+mainlooplar,vs.vs. sürecinin de bir overhead'i 
olacak sonuçta.

Bir de hazır konular bir yerinden örtüşüyorken söyleyeyim. Yazıcı tanıma 
aracı için bilgisayar ilk açıldığında HAL yeni bir yazıcı tanımlarsa 
bunun zaten sistemde olup olmadığını anlamak için CUPS ile iletişime 
geçiyor ancak kendisi HAL'den sonra başlatıldığı için bu iletişim yalan 
oluyor. 2008'de, CUPS'ın HAL'den önce başlamasını sağlamakta sakınca var 
mıdır?

Gelişmeleri heyecanla takip ediyorum comar-dbus hususunda, ellerine sağlık.

-- 
Ozan ÇAĞLAYAN
http://cekirdek.pardus.org.tr/~ozan
<ozan_at_pardus.org.tr>