Ben bildiğim kadarını yazacağım ama en doğrusunun bu gibi sistem konularını ve kütüphanelerini kendi kaynaklarından okumak olduğunu düşünüyorum.
Örneğin, çalıştığım yerde biz libevent kullanıyoruz ama o kütüphanenin yeteneklerinden yalnızca bizim işimize yarayan kadarını kullanıyoruz.
Alıntı (darkofpain):
> event,epoll,kqueue bunlarla karşılaştım.
libevent, sistemde gerçekleşen ve programı ilgilendiren olayları olay (event) olarak sunar:
-
Sinyaller. Örneğin, program bir alt program başlatmıştır; o program sonlandığında başlatana SIGCHLD sinyali gelir; libevent o sinyali bir "şu sinyal oluştu" olayı olarak gösterir.
-
Zamanlayıcılar (timer). Örneğin, program her bilmem kaç saniyede bir işlem yapmak ister; onun için bir zamanlayıcı başlatır ve libevent onu "şunun zamanı geldi" olayı olarak gösterir.
-
Dosya okuma ve yazma. Örneğin, program uzun bir yazma işlemi başlatır ve libevent "şu yazma bitti" olayı olarak gösterir.
-
vs.
İşin güzeli, doğal olarak eş zamanlı gerçekleşen bu tür olaylar programda tek iş parçacığı tarafından halledilebilir. Bu, programda olay döngüsü (event loop) denen döngüde programın "sıradaki olay nedir" diye sorması ve her seferinde libevent'in sunduğu tek olaya yanıt vermesi ile sağlanır.
Benim çalıştığım yerde libevent aynı bu biçimde kullanılıyor: Programımız tek iş parçacığı üzerinde çalışıyor ama her olay kendi başına gelişirken aynı anda birden çok iş yapılmış oluyor.
Yan bilgi olarak, programımızın tek iş parçacığı üzerinde çalışıyor olmasının tek nedeni, alt düzey kütüphanemizin C dilinde yazılmış olması ve eş zamanlı programlamanın C'de hataya açık olması. On sene önce bu tasarımı yapan programcılar çok doğru bir karar vermişler ve bu sayede bu program on senedir ayakta kalabilmiş. libevent yerine C'de veri paylaşımına dayanan eş zamanlı programlama kullansalar işin içinden çıkılamazdı.
Alıntı:
> Ayrıca burada ali hocanın yaptığı örnekte her gelen bağlantı için bir işçi başlatması ve işlemleri onun üzerinden yapması gibi örneklemeler yaptık ancak bu yöntem tam olarak doğru yöntem değil
Mühendislik açısından bakınca her yöntem durumuna göre en doğru yöntem olabilir. Ama evet, iş parçacıklarının genel sorunları iş parçacığı kullanan her programda ortadadır.
Alıntı:
> D ile bunlar nasıl kullanılıyor
O konuda libevent ilintilerinin var olduğun dışında bir bilgim yok:
https://github.com/D-Programming-Deimos/libevent
Alıntı:
> Yapmak istediğim olayın genel adı "Asynchronous Networking / Non-Blocking I/O"
Genel adı o ama özel bir uygulamasını arıyorsun çünkü o çok genel kavramların buradaki örneklerinin işine yaramadığını biliyoruz.
Alıntı:
> Vibe.d nin performansı hakkında şurada bir yazısı var. http://vibed.org/features (Performans başlığı altında)
Hızlıca göz gezdirince Vibe.d'nin fiber'ları (başka adıyla co-routine) nasıl etkin olarak kullandığından bahsediliyor. Fiber, eş zamanlı işleri farklı iş parçacıklarına yaptırmak yerine aynı iş parçacığının farklı işleri parça parça ilerletmesi temeline dayanır.
Python'daki 'yield' anahtar sözcüğü ile o dilin temel bir olanağıdır. Go dilinde de "goroutine" diye geçer. D'de dilin temel olanağı olmadığı için kütüphane olanakları olarak çözülür. Bu konuda da deneyimim yok ama en azından Phobos'ta core.thread.Fiber olduğunu biliyorum:
http://dlang.org/phobos/core_thread.html#.Fiber
Ali
--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]