signal handlers

[migf1]

 

 

Φυσικά, αλλά ανήκουν στον εκάστοτε window manager: π.χ. http://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-main-iteration και http://tronche.com/gui/x/xlib/event-handling/manipulating-event-queue/XNextEvent.html.

 

Στα Windows ο window manager θεωρείται "μέρος του λειτουργικού" παρόλο που δεν υπαρχει τεχνικά λόγος γι' αυτό (τρέχει φυσικά στη userland: user32.dll), οπότε δεν έχεις τέτοιες "επιλογές".

 

Τελικά μιλάμε για messaging μεταξύ kernel & user spaces ή για το εσωτερικό messaging high-level gui's;

 

Διότι τόσο το GTK όσο και το X-Windows στα οποία αναφέρονται τα παραδείγματά σου αφορούν τις custom, εσωτερικές high-level υλοποιήσεις των δικών τους events (και όχι events/signals προερχόμενα από το kernel).

[defacer]

Το topic μιλάει για signals. Το παπί μίλησε για "dispatcher", εννοώντας window messages. Είναι τελείως διαφορετικά πράγματα.

[migf1]

Το topic μιλάει για signals. Το παπί μίλησε για "dispatcher", εννοώντας window messages. Είναι τελείως διαφορετικά πράγματα.

 

Για αυτό ζήτησα κι εγώ διευκρίνηση (συν επειδή ο παπι ρώτησε ειδικώς για *nix, και όχι για κάποιο x-platform GUI).

 

Υποθέτω ο παπι δεν είναι εξοικειωμένος με *nix, εξού και η ερώτησή του (εξού και το μπέρδεμα). Οπότε θα προσπαθήσω συνοπτικά να το εξηγήσω...

 

Μια διαφορά μεταξύ *nix και Win είναι πως η Microsoft επέλεξε (κατά τα πρότυπα της Apple με τον Macintosh) να ενσωματώσει το GUI στον πυρήνα του λειτουργικού. Αυτό προσδίδει ομοιογενή εμφάνιση αλλά και διαχείριση του GUΙ, αλλά από την άλλη μεριά αν καταρρεύσει το GUI παρασύρει μαζί του όλο το σύστημα.

 

Στο *nix, το GUI είναι ανεξάρτητο, με τα ανάποδα πλεονεκτήματα και μειονεκτήματα.

 

Οπότε σε *nix context, τα signals είναι ένα (περιορισμένων δυνατοτήτων) messaging-mechanism μεταξύ kernel και user processes, που δεν έχει δηλαδή να κάνει με GUI's. Τη βασική λογική τους προσπάθησα να την εξηγήσω στο προηγούμενο ποστ. Οι λεπτομέρειες είναι προφανώς πολύ περισσότερες, ενώ συχνά και οι συναρτήσεις διαχείρισης των signals είναι implementation/platform dependent ή έχουν διάφορα unspecified states.

 

Για παράδειγμα η sigqueue()

 

Αυτό που ισχύει πάντα όμως (εκτός αν έχει αλλάξει κάτι δραστικά και δεν το έχω πάρει είδηση, μιας και έχω καιρό να ασχοληθώ) είναι πως τα signals δημιουργούνται από το kernel. Μπορούν και τα user-space processes να επικοινωνήσουν μεταξύ τους με signals (permissions επιτρέποντος) αλλά όχι απευθείας. Πρέπει να στείλουν στο kernel την αίτησή τους για αποστολή ενός signal σε ένα άλλο process, κι αυτό αναλαμβάνει να δημιουργήσει και να στείλει στην receiving process το signal που αιτήθηκε η sending process.

[Timonkaipumpa]

defacer

 

 

 

Κάπου άκουσα ότι από τα Windows 7 και πέρα έχει αλλάξει αυτό το μεγάλο switch των windows και έχει γίνει event based.

 

Αληθεύει ή όχι;

 

 

[migf1]

defacer

 

 

 

Κάπου άκουσα ότι από τα Windows 7 και πέρα έχει αλλάξει αυτό το μεγάλο switch των windows και έχει γίνει event based.

 

Αληθεύει ή όχι;

 

 

 

 

 

Για εξήγησέ το λίγο παραπάνω αυτό ρε συ Timon, γιατί σε έχασα. Τι εννοείς; Υποθέτω αναφέρεσαι σε κάτι διαφορετικό από την εντολή switch της C/C++ η οποία είναι ο συνηθέστερος τρόπος διαχείρισης events σε όλες τις HL event-based εφαρμογές (GUI included).

 

Σωστά;

 

Δηλαδή, αναφέρεσαι σε GUI context, σε kernel, σε κάτι άλλο?

 

 

 

[defacer]

@timon

Δεν είμαι σίγουρος σε τι αναφέρεσαι. Σίγουρα δεν έχει αλλάξει το ότι μια window procedure γραμμένη με το χέρι σε C θα περιλαμβάνει ένα switch-Godzilla. Επίσης (ψιλοσχετικό) νομίζω πως πρέπει να προσέχουμε με την έκφραση "event-based" που έχει αρχίσει να χρησιμοποιείται αρκετά στο thread -- είναι πολύ εύκολο (μη πω σίγουρο) πως ο καθένας την αντιλαμβάνεται διαφορετικά.

 

@migf1

Και για κατούρημα να θέλει να πάει μια process πρέπει να ρωτήσει τον kernel πρώτα. Δεν προβλέπονται αλλαγές σ' αυτό το θέμα...

[migf1]

...

@migf1

Και για κατούρημα να θέλει να πάει μια process πρέπει να ρωτήσει τον kernel πρώτα. Δεν προβλέπονται αλλαγές σ' αυτό το θέμα...

 

Ναι, σε kernel context.

 

Σε GUI context όμως τα HL signals του δεν είναι καθόλου απαραίτητο να περνάνε από το OS (π.χ. GTK, που αναφέρθηκε ήδη)... βασικά στην συντριπτική πλειοψηφία δεν ασχολούνται με το kernel, αλλά με την δικιά τους εσωτερική υλοποίηση.

 

Θέλησα να κάνω ξεκάθαρο τον διαχωρισμό, αν και στα Windows δεν ξέρω τι ακριβώς συμβαίνει... βασικά, λειτουργικά που ενσωματώνουν το GUI στον πυρήνα τους είναι ελεύθερα να δένουν τα HL signals του GUI με τα low-level signals του λειτουργικού όσο tightly ή όσο loosely επιθυμούν.

 

ΥΓ. Ίσως είναι καλή ιδέα να ανοιχτεί διαφορετικό νήμα για τα HL signals των GUI (ή όποιων άλλων HL event-based εφαρμογών).

[defacer]

Η οποία δική τους εσωτερική υλοποίηση σε κάποια σημεία καλεί πιθανότατα τον kernel, μιας και για την πιο απλή γενική περίπτωση ενός producer/consumer κάποια στιγμή χρειάζεται να γράψεις "περίμενε μέχρι να υπάρχει κάτι για consumption". Το οποίο περίμενε γίνεται με έναν από τους παρακάτω τρόπους:

1. Κάνοντας busy wait (οπότε σε δένουν ημίγυμνο στην πλατεία όπου συγκεντρωμένοι προγραμματιστές VB σου πετάνε σάπιο φαγητό και λεκτικές προσβολές -- εκτός από συγκεκριμένες περιπτώσεις που εξαιρούνται λόγω ανωτέρας βίας)
   
2. Υλοποιώντας userland threads μόνος σου με coroutines (οπότε καταλαβαίνουμε ότι γράφεις database server)
   
3. Καλώντας τον kernel (σε όλες τις υπόλοιπες περιπτώσεις)
   

[migf1]

Δεν καταλαβαίνω τι εννοείς. Κατά κανόνα τα GUI HL signals είναι custom και δεν έχουν απολύτως καμία σχέση με τα kernel signals (συν ότι είναι απείρως περισσότερα).

 

Π.χ. στο GTK είναι class methods του HL API: http://developer.gnome.org/gtk/2.24/gtk-Signals.html

[defacer]

Εννοώ αυτό που είπα: όταν μιλάμε για GUI, κάποια στιγμή θα πρέπει να περιμένεις να γίνει "κάτι". Γι' αυτή την αναμονή θα πας στον kernel (σενάριο #3).

 

Δε νομίζω πάντως ότι βοηθάει τη συνεννόηση το να μιλάς για "HL signals" στο context κάποιου framework. Στην ουσία όλα αυτά είναι υλοποιήσεις του pub/sub pattern οι οποίες κατά περίπτωση τυχαίνει να ονομάζονται "signals and slots". Θα μπορούσε εξίσου καλά να ονομάζεται "πίτα και γύρος", γιατί εδώ οι λέξεις signal και slot δεν έχουν κάποια συγκεκριμένη τεχνική έννοια (σε αντίθεση με αυτό που ισχύει όταν μιλάμε για POSIX signals). Σε άλλες περιπτώσεις ονομάζονται "events" αλλά κι αυτό δεν είναι πολύ βοηθητικό γιατί η λέξη χρησιμοποιείται από πολύ κόσμο για να περιγράψει τελείως διαφορετικά πράγματα.

 

Οπότε, context: τα HL signals (όπως το λες) σαφώς και δεν περνάνε από kernel. Αλλά το γενικό control flow ενός window manager περνάει από kernel, είτε αυτός περνάει τα μηνύματα στον κώδικά σου με pub/sub είτε με οποιοδήποτε άλλο τρόπο.

[migf1]

Εγώ εξακολουθώ να μην καταλαβαίνω τι σχέση έχει π.χ. το button "clicked" signal του GTK με οποιοδήποτε *nix kernel signal. Ούτε τι σχέση έχει π.χ. το window "destroyed" signal του GTK με το ότι όλα τα προγράμματα ανεξαιρέτως επικοινωνούν ενδόμυχα με το kernel του OS για σχεδόν οτιδήποτε κάνουν.

 

 

EDIT:

 

Δηλαδή με απλά λόγια, στο *nix kernel δεν υπάρχει signal για το αν π.χ. ο χρήστης ενός GUI διάλεξε με το ποντίκι του ένα menu entry, ή π.χ. έκανε κλικ σε ένα dialog-button, οπότε και του είναι αδύνατον να παράξει signals τα οποία δεν γνωριζει.

 

EDIT2

 

Ξέχασα, το ότι το *nix kernel μπορεί να διαχειριστεί custom signals (SIGUSR1 and SIGUSR2) σε καμία περίπτωση δεν σημαίνει πως τα GUIs δουλεύουν έτσι. Κατά κανόνα, δεν!

[παπι]

Φυσικά, αλλά ανήκουν στον εκάστοτε window manager: π.χ. http://developer.gno...-main-iteration και http://tronche.com/g...XNextEvent.html.

 

Στα Windows ο window manager θεωρείται "μέρος του λειτουργικού" παρόλο που δεν υπαρχει τεχνικά λόγος γι' αυτό (τρέχει φυσικά στη userland: user32.dll), οπότε δεν έχεις τέτοιες "επιλογές".

Α μαλιστα. Αρα ο nix kernel το μονο που σου προσφερει απο τα "ετσι" ειναι το filesystem.

 

Βασικα μπερδευτηκα διοτι στην εννοια του kernel των windows ως πυρηνας συμπεριλαμβανεται και το user32 ασχετα αν εχει περιορισμενα δικαιωματα.

[migf1]

...

Στα Windows ο window manager θεωρείται "μέρος του λειτουργικού" παρόλο που δεν υπαρχει τεχνικά λόγος γι' αυτό (τρέχει φυσικά στη userland: user32.dll), οπότε δεν έχεις τέτοιες "επιλογές".

 

Επειδή μου κίνησε την περιέργεια, γκουγκλάρισα λίγο και αν όσα γράφει η Wikipedia ισύχουν, τότε ο Windows Manager στα Windows από το 2007 και δώθε τρέχει σε kernel space, κι απλώς παρέχει ένα user-space interface ως higher-level means of communication.

 

http://en.wikipedia.org/wiki/Hybrid_kernel

...

The primary operating system personality on Windows is the Windows API, which is always present. The emulation subsystem which implements the Windows personality is called the Client/Server Runtime Subsystem (csrss.exe). On versions of NT prior to 4.0, this subsystem process also contained the window manager, graphics device interface and graphics device drivers. For performance reasons, however, in version 4.0 and later, these modules (which are often implemented in user mode even on monolithic systems, especially those designed without internal graphics support) run as a kernel-mode subsystem.

...

Το συγκεκριμένο άρθρο το βρήκα άκρως ενημερωτικό, γενικώς.

 

Επίσης, right from the horse's mouth...

 

http://technet.microsoft.com/library/cc750820.aspx

...

Microsoft Windows NT Workstation 4.0 and Windows NT Server 4.0 include a change in the implementation of Win32 graphics-related application programming interfaces. These changes are transparent to applications and users, yet they result in a variety of improvements to graphics performance and memory requirements, as well as to simplify the design of the Windows NT Win32 subsystem. The improvements result from the move of certain operating system modules from a user-mode application process into a subsystem within the privileged portion of Windows NT, known as the Executive.

 

Changes to the code that operates in the kernel or privileged mode of any operating system can be of concern to application designers and system architects. Because such changes potentially affect the operating system's compatibility with existing applications, as well as its portability and reliability, such changes should be explained and justified.

 

This white paper provides a basic understanding of the issues and justifications surrounding this change and its effect on customers and developers. It explains how this change will provide improvements to the operation of the systemsuch as performance and memory requirementswhile leaving the critical factors of application compatibility, scalability, portability, and reliability unaffected.

...

 

Και τα δυο άρθρα εξηγούν τους λόγους για αυτή την design-decision change, που εν πολλοίς περικλείεται σε μια λέξη: performance.

 

Προσωπικά δεν γνώριζα για αυτό το hybrid υπόβαθρο των Windows, και πιο συγκεκριμένα για τα OS personalities του σε τόσο χαμηλό επίπεδο (παρόλο που π.χ. ήξερα πως υπάρχει ένα unix-like layer της Microsoft, το οποίο όμως νόμιζα πως ήταν κάτι σαν το Cygwin)

 

 

 

@papi: Και πάνω που πήγες να ξεμπερδευτείς, ε;

 

 

[Directx]

Το μυστικό για το υβριδικό υπόβαθρο των Windows είναι μια παρενέργεια (ας πούμε) από την σχέση Microsoft & IBM, ο Kernel σχεδιάστηκε κατά τρόπο τέτοιο που του επέτρεπε να τρέχει είτε Win32, είτε το OS/2 API είτε μια μορφή POSIX (επίσης ο Kernel είναι γραμμένος με abstract φιλοσοφία ώστε να τρέχει και σε CPUs πέραν των Intel 80x86). Ο στόχος ήταν η ομαλή μετάβαση όλων στο Win32 καθώς υπήρχαν επιχειρήσεις που βασιζόντουσαν εκείνη την εποχή στο OS/2. Τελικά το OS/2 δεν πήγε πολύ μακριά (τελευταία αναλαμπή του το OS/2 WARP αν θυμάμαι καλά), το POSIX επίσης (όποιος ήθελε Unix πήγαινε σε καθαρή υλοποίηση) οπότε έμεινε το Win32 και κάπου εκεί ενοποιήθηκε τελικά και το UI (USER32) στον Kernel ακριβώς για λόγους ταχύτητας (ήταν πια η εποχή που τα PC βάδιζαν σε NT Kernels.. από τα απλά 32/16bit '9x).

[imitheos]

Το μυστικό για το υβριδικό υπόβαθρο των Windows είναι μια παρενέργεια (ας πούμε) από την σχέση Microsoft & IBM, ο Kernel σχεδιάστηκε κατά τρόπο τέτοιο που του επέτρεπε να τρέχει είτε Win32, είτε το OS/2 API είτε μια μορφή POSIX (επίσης ο Kernel είναι γραμμένος με abstract φιλοσοφία ώστε να τρέχει και σε CPUs πέραν των Intel 80x86). Ο στόχος ήταν η ομαλή μετάβαση όλων στο Win32 καθώς υπήρχαν επιχειρήσεις που βασιζόντουσαν εκείνη την εποχή στο OS/2. Τελικά το OS/2 δεν πήγε πολύ μακριά (τελευταία αναλαμπή του το OS/2 WARP αν θυμάμαι καλά), το POSIX επίσης (όποιος ήθελε Unix πήγαινε σε καθαρή υλοποίηση) οπότε έμεινε το Win32 και κάπου εκεί ενοποιήθηκε τελικά και το UI (USER32) στον Kernel ακριβώς για λόγους ταχύτητας (ήταν πια η εποχή που τα PC βάδιζαν σε NT Kernels.. από τα απλά 32/16bit '9x).

 

+1

 

Ωραίος. Μα ιστορική πληροφορία θα είναι, μα σωστή μεθοδολογία για το Χ πρόβλημα θα είναι, πάντα μπορείς να βασιστείς στον DirectX και στον defacer ότι θα σου μάθουν κάτι σε κάθε post τους.