QNX RTOS: इंटर-वर्क

QNX रीयल-टाइम ऑपरेटिंग सिस्टम पर नोटों की श्रृंखला की निरंतरता। इस बार मैं QNX न्यूट्रिनो में इंटर-टास्किंग के बारे में बात करना चाहूंगा (हम QNX 6.5.0 पर विचार करेंगे)। आरटीओएस में, अंतर-कार्य अंतःक्रिया के लिए तंत्र की एक विस्तृत श्रृंखला है, क्यूएनएक्स-विशिष्ट मैसेजिंग से लेकर यूनिक्स और पोसिक्स डेवलपर्स और साझा की गई मेमोरी तक जाने वाले सिग्नल। और यद्यपि अधिकांश नोट मैसेजिंग के लिए समर्पित होंगे, लेकिन सिग्नल, पॉसिक्स संदेशों और साझा मेमोरी का उपयोग करने की सुविधाओं का भी वर्णन किया जाएगा। और अंत तक पढ़ने वालों को चाय के लिए दो बन्स मिलेंगे।

संदेश के सिद्धांत को समझना QNX सिस्टम प्रोग्रामर के लिए आवश्यक है, जैसा कि यह तंत्र RTOS में एक मौलिक भूमिका निभाता है। ऑपरेटिंग सिस्टम के कई कार्य जो डेवलपर्स के लिए परिचित और परिचित हैं, वे केवल ऐड-ऑन हैं और मैसेजिंग (उदाहरण के लिए, read() और write() ) का उपयोग करके कार्यान्वित किए जाते हैं।

QNX RTOS इंटरटेकिंग फॉर्म

जैसा कि ऊपर उल्लेख किया गया है, संदेश QNX में इंटर-टास्किंग इंटरैक्शन के लिए मूलभूत तंत्र है, जिस पर कुछ अन्य तंत्र आधारित हैं। इस नोट में चर्चा किए गए अंतर-कार्य सहभागिता के सभी रूपों को नीचे दी गई तालिका में सूचीबद्ध किया गया है, जो दर्शाता है कि इस या उस तंत्र को लागू करने के लिए कौन जिम्मेदार है।

तालिका 1. अंतर-कार्य सहभागिता के रूप।

तंत्र	कार्यान्वयन का क्षेत्र
संदेश सेवा	microkernel
संकेत	microkernel
साझा की गई स्मृति	procnto प्रक्रिया procnto
POSIX संदेश कतार	mqueue प्रबंधक
(पाइप) और नामित (फीफो) प्रोग्राम चैनल	pipe प्रबंधक

QNX 6.5.0 RTOS में, इंटर-टास्क इंटरैक्शन का एक और रूप सामने आया है - पर्सेंटेज पब्लिश / सब्सक्राइब (PPS)। यह एक दिलचस्प तकनीक है, जिसे मैं एक और बार लिखने की कोशिश करूंगा। जो रुचि रखते हैं वे "QNX न्यूट्रूनो सिस्टम आर्किटेक्चर" से पीपीएस अनुभाग का अनुवाद पढ़ सकते हैं।

संदेश सेवा

यह QNX न्यूट्रीनो माइक्रोकर्नेल में लागू एक सिंक्रोनस इंटर-टास्किंग तंत्र है। RTOS विकसित करते समय, अंतर-कार्य सहभागिता के इस रूप को गलती से मुख्य के रूप में नहीं चुना गया था। सबसे पहले, तंत्र ही काफी सरल है। दूसरे, संदेश संचरण और रिसेप्शन का सिंक्रनाइज़ेशन डीबगिंग की सुविधा देता है। तीसरा, QNX न्यूट्रिनो मैसेजिंग पर आधारित बातचीत के उच्च-स्तरीय रूपों (उदाहरण के लिए, सॉफ्टवेयर चैनल) का परीक्षण और एक अखंड कर्नेल में लागू किया गया, लगभग एक ही प्रदर्शन विशेषताओं का पता चला।

मैसेजिंग ¹ में उपयोग किए जाने वाले तीन मुख्य कार्यों के पहले अक्षरों के आधार पर QNX मैसेजिंग इंजन को SRR इंजन भी कहा जाता है। संदेश भेजने के लिए MsgSend() का उपयोग किया जाता है, MsgReceive() संदेश प्राप्त करने के लिए होता है, और MsgReply() कॉल करने वाले को प्रतिक्रिया भेजने के लिए होता है। सबसे पहले, हम प्रत्येक फ़ंक्शन को व्यक्तिगत रूप से समझते हैं कि वे कैसे काम करते हैं, और फिर उन्हें एक उदाहरण में जोड़ते हैं। कार्यों के सभी तर्कों को जानबूझकर नहीं दिया जाएगा ताकि विचलित न हों और पहले ऑपरेशन के सिद्धांत को समझें।

MsgSend() का उपयोग क्लाइंट से सर्वर पर संदेश भेजने और प्रतिक्रिया प्राप्त करने के लिए किया जाता है । यहाँ ग्राहक और सर्वर की अवधारणाएँ मनमानी हैं, क्योंकि एक ही कार्यक्रम कुछ कार्यों के लिए एक सर्वर हो सकता है और, एक ही समय में, दूसरों का क्लाइंट। उदाहरण के लिए, डेटाबेस सर्वर डेटाबेस क्लाइंट ^{2 के} लिए एक सर्वर है। और एक ही समय में, डेटाबेस सर्वर फ़ाइल सिस्टम मैनेजर के लिए क्लाइंट होगा। जब MsgSend() फ़ंक्शन को MsgSend() क्लाइंट को दो राज्यों में से एक में अवरुद्ध किया जाता है: SEND या REPLY । SEND स्थिति का मतलब है कि ग्राहक ने संदेश भेजा है और सर्वर ने अभी तक इसे प्राप्त नहीं किया है। सर्वर द्वारा संदेश प्राप्त करने के बाद, ग्राहक REPLY स्थिति में प्रवेश करता है। जब सर्वर प्रतिक्रिया संदेश देता है, तो क्लाइंट अनलॉक हो जाता है।

MsgReceive() का उपयोग क्लाइंट से संदेश प्राप्त करने के लिए किया जाता है । सर्वर कॉल करता है MsgReceive() और MsgReceive() स्थिति में ब्लॉक करता है यदि क्लाइंट में से किसी ने भी अभी तक कोई संदेश नहीं भेजा है, अर्थात। MsgSend() फ़ंक्शन को कॉल नहीं किया। इसके बाद ( सर्वर को एक संदेश भेजा गया था)। सर्वर अनलॉक है और निष्पादित करना जारी रखता है। सर्वर को आमतौर पर प्राप्त संदेश को संसाधित करने और एक नया प्राप्त करने के लिए तैयार करने के लिए कुछ क्रियाएं करने की आवश्यकता होती है। यदि सर्वर कई थ्रेड्स में चल रहा है, तो एक अन्य थ्रेड संदेश को संसाधित कर सकता है और क्लाइंट को रिप्लाई कर सकता है। सबसे अधिक बार, संदेश प्राप्त करने वाली धारा एक "शाश्वत" चक्र में काम करती है और, प्राप्त संदेश को संसाधित करने के बाद, MsgReceive() फिर से कॉल MsgReceive() ।

MsgReply() उपयोग क्लाइंट ³ को एक प्रतिक्रिया संदेश भेजने के लिए किया जाता है। जब MsgReply() फ़ंक्शन को MsgReply() लॉक नहीं होता है, अर्थात। सर्वर आगे काम करना जारी रखेगा। ऐसा इसलिए है क्योंकि क्लाइंट पहले से ही लॉक अवस्था ( REPLY ) में है और अतिरिक्त सिंक्रनाइज़ेशन की आवश्यकता नहीं है।

ज्ञान ईंटों से QNX मैसेजिंग तंत्र को समझने के लिए पुल बनाने के लिए और क्या सीखने की आवश्यकता है? इतना नहीं है। धैर्य रखें, अब तस्वीर आकार लेना शुरू कर देगी।

QNX न्यूट्रीनो माइक्रोकर्नेल प्रेषित संदेश की सामग्री के बारे में परवाह नहीं करता है। संदेशों का कोई प्रारूप नहीं है। संदेश केवल क्लाइंट और सर्वर के लिए समझ में आता है । माइक्रोकर्नल केवल क्लाइंट एड्रेस स्पेस से सर्वर एड्रेस स्पेस (और रिस्पांस करते समय इसके विपरीत) संदेश (यानी सिर्फ एक डेटा बफर) को कॉपी करता है और संदेशों को संग्रहीत करने के लिए कोई मध्यवर्ती बफर नहीं होता है। और इसका मतलब है कि कोई मध्यवर्ती नकल नहीं है, क्योंकि माइक्रोकर्नल क्लाइंट मेमोरी से सर्वर मेमोरी (और जवाब देते समय इसके विपरीत) के डेटा को सीधे कॉपी करता है। परिणामस्वरूप, मैसेजिंग इंजन का प्रदर्शन बढ़ जाता है।

एक संदेश के प्रसारण, स्वागत और प्रतिक्रिया को सिंक्रनाइज़ करने के लिए, माइक्रोकर्नल तीन राज्यों में से एक में संदेश एक्सचेंज में भाग लेने वाले थ्रेड्स को ब्लॉक करता है: SEND , RECIEVE और REPLY । क्लाइंट को SEND स्थिति में तब तक ब्लॉक किया जाता है जब तक सर्वर को उसका संदेश नहीं मिल जाता। यदि कोई क्लाइंट इसे संदेश नहीं भेजता है तो सर्वर RECEIVE स्थिति में अवरुद्ध है। सर्वर द्वारा संदेश प्राप्त करने के बाद, इसे अनलॉक किया जाता है, और ग्राहक REPLY अवरुद्ध अवस्था में चला जाता है। सर्वर क्लाइंट को प्रतिक्रिया देता है, बाद में अनलॉक किया जाता है। वह सब है।

इसलिए, हमें पता चला कि QNX में मैसेजिंग इंजन कैसे काम करता है। अंजीर। 1 बस ऊपर चित्र दिखाता है।


अंजीर। 1. QNX न्यूट्रिनो में मैसेजिंग।

क्लाइंट को सर्वर कैसे मिलता है?

यदि आप QNX RTOS में मैसेजिंग इंजन के सिद्धांत को समझते हैं, तो आप आगे बढ़ सकते हैं। संभवतः, आपके पास एक प्रश्न होना चाहिए, जो यह तय किए बिना, आप QNX में संदेशों का आदान-प्रदान नहीं कर पाएंगे। क्लाइंट को सर्वर कैसे मिलता है?

संदेश सीधे थ्रेड्स के बीच प्रसारित नहीं होते हैं। इसके बजाय, चैनल और कनेक्शन का उपयोग किया जाता है। सर्वर ChannelCreate() फ़ंक्शन का उपयोग करके चैनल बनाता है। अब, अंत में, सर्वर एक स्पष्ट विवेक के साथ, MsgReceive() और MsgReply() कॉल कर MsgReceive() । नीचे दिए गए कोड का टुकड़ा सर्वर के संचालन को दर्शाता है :

 chid = ChannelCreate( flags ); /*    chid  -1 */ for (;;) { rid = MsgReceive( chid, &msg, sizeof( msg ), NULL ); /*    rid  -1 */ switch ( msg.type ) { /*   */ } MsgReply( rid, EOK, NULL, 0 ); /*    ,    */ } 

बदले में, क्लाइंट ConnectAttach() का उपयोग कर सर्वर चैनल से एक कनेक्शन बनाता है, और फिर MsgSend() कॉल MsgSend() । ग्राहक कोड काफी सरल है:

 coid = ConnectAttach( nd, pid, chid, _NTO_SIDE_CHANNEL, 0 ); /*    coid  -1 */ /*   */ MsgSend( coid, smsg, sizeof( smsg ), rmsg, sizeof( rmsg ) ); /*    ,    */ /*   */ 

अब आखिरी सवाल बचता है। chid सर्वर पैरामीटर कैसे chid है : nd , pid , chid ? ये पैरामीटर एक शहर के कोड और एक्सटेंशन नंबर के साथ एक सर्वर पते या यहां तक ​​कि एक फोन नंबर का प्रतिनिधित्व करते हैं। इस प्रश्न का उत्तर का आधा हिस्सा यह है कि सर्वर स्वयं इन सभी मापदंडों को जानता है। लेकिन सर्वर उन्हें क्लाइंट से कैसे संवाद कर सकता है?

सर्वर से यह जानकारी प्राप्त करने के विभिन्न तरीके हैं। आप .pid फ़ाइलों या वैश्विक चर का उपयोग कर सकते हैं। लेकिन छोटे अनुप्रयोगों के लिए सही तरीका सर्वर में name_attach() फ़ंक्शन और क्लाइंट में name_open() का उपयोग करना है । एक और भी सही तरीका सर्वर को संसाधन प्रबंधक ^{4 के} रूप में लागू करना है , जब यह नाम स्थान तत्व के लिए जिम्मेदार है।

मिश्रित संदेश

जैसा कि पहले ही उल्लेख किया गया है, QNX न्यूट्रिनो में मैसेजिंग इंजन के मुख्य लाभों में से एक इसका उच्च प्रदर्शन है। यह इस तथ्य से प्राप्त होता है कि डेटा की कोई मध्यवर्ती प्रतिलिपि नहीं है, अर्थात्। संदेश ग्राहक की मेमोरी से सर्वर की मेमोरी में सीधे कॉपी किया जाता है। अक्सर ऐसा होता है कि ये संदेश अलग-अलग जगहों पर होते हैं। एक विशिष्ट मामला तब है जब डेटा उपकरण से प्राप्त एक कच्चा बफर है और डेटा जानकारी (संदेश हेडर) के साथ एक संरचना है। कच्चा डेटा स्वयं रिंग बफर में स्थित हो सकता है। क्या इस मामले में वास्तव में आवश्यक है कि एक अलग बफर तैयार करें और हेडर और डेटा को रिंग बफर से कॉपी करें? क्या यह एक अतिरिक्त प्रति होगी? संदेश भेजने से पहले डेटा की इस शानदार प्रतिलिपि को QNX RTOS में टाला जा सकता है यदि समग्र संदेश का उपयोग किया जाता है।

QNX न्यूट्रिनो में समग्र संदेशों की iov_t करने के iov_t , आपको संदेशों की संख्या (या अधिक) के बराबर तत्वों की संख्या के साथ, और SETIOV() मैक्रो, अर्थात का उपयोग करके प्रत्येक तत्व को इनिशियलाइज़ करने के लिए, iov_t एक प्रकार की घोषणा करनी चाहिए। प्रत्येक बफ़र का पता और आकार निर्दिष्ट करें। अंजीर। 2 समग्र संदेशों के सिद्धांत को दर्शाता है।


अंजीर। 2. एक समग्र संदेश का एक उदाहरण।

यौगिक संदेशों के साथ काम करने के लिए, परिचित कार्य MsgReceive() और MsgReply() , लेकिन v के अंत के साथ, अर्थात। MsgReceivev() और MsgReplyv() । चूंकि संदेश भेजने वाला फ़ंक्शन MsgSend() भी परिणाम को स्वीकार करता है, यह एक पूरे परिवार से MsgSendv() : MsgSendv() , MsgSendsv() और MsgSendvs() । अब माइक्रोकर्नल हमारे लिए सभी अतिरिक्त काम करेगा, और पूरे संदेश के साथ कोई अतिरिक्त प्रतिलिपि और बफर नहीं होगा। मुझे यह पसंद है!

दालों

कभी-कभी केवल दूसरे धागे को सूचित करने के लिए आवश्यक है कि कुछ हुआ, और उत्तर की आवश्यकता नहीं है। इसलिए MsgSend() पर ब्लॉक करना आवश्यक नहीं है। इस स्थिति में, MsgSendPulse() फ़ंक्शन MsgSendPulse() लिए आता है। एक पल्स में 8 बिट्स कोड और 32 बिट्स डेटा होते हैं। बहुत बार, दालों का उपयोग बाधित हैंडलर में किया जाता है। दालों के लिए, कतारों का उपयोग किया जाता है, अर्थात यदि कुछ समय के लिए धारा उन्हें प्राप्त नहीं हुई है, तो दालों का नुकसान नहीं होगा। लेकिन जल्द ही या बाद में एक EAGAIN त्रुटि प्राप्त करने के लिए तैयार रहें यदि आप किसी स्ट्रीम में दाल भेजते हैं जिसमें उन्हें पढ़ने का समय नहीं है।

संकेत

QNX न्यूट्रिनो RTOS एक सिग्नलिंग तंत्र का समर्थन करता है जो UNIX डेवलपर्स से परिचित होना चाहिए। दोनों मानक POSIX सिग्नल और POSIX वास्तविक समय सिग्नल समर्थित हैं। दोनों प्रकार के संकेतों के साथ काम करने के लिए, एक ही माइक्रोकर्नेल कोड का उपयोग किया जाता है। नतीजतन, माइक्रोकर्नल अपने आप छोटा हो जाता है, और पोसिक्स सिग्नल (एप्लिकेशन के अनुरोध पर) पोसिक्स रीयल-टाइम सिग्नल समूह के अपने सहयोगियों की तरह कतारबद्ध हो सकते हैं। अन्य बातों के अलावा, QNX न्यूट्रिनो POSIX मानक का विस्तार करता है और आपको एक विशिष्ट स्ट्रीम में सिग्नल भेजने की अनुमति देता है। और यह कभी-कभी बहुत उपयोगी होता है।

वैसे, POSIX वास्तविक समय के संकेतों में 8 बिट्स कोड और 32 बिट्स डेटा होते हैं। क्या कुछ भी समान नहीं है? सटीक रूप से, वही कोड जो सिग्नल तंत्र को लागू करता है, का उपयोग दालों के प्रसारण में भी किया जाता है। सुविधाजनक और विश्वसनीय।

संकेतों के साथ काम करने के लिए, परिचित फ़ंक्शंस kill() , sigaction() , sigprocmask() , आदि, साथ ही साथ अधिक दिलचस्प वाले, उदाहरण के लिए, pthread_kill() और pthread_sigmask() ।

कार्यक्रम चैनल

सॉफ्टवेयर चैनलों को यूनिक्स उपयोगकर्ताओं और डेवलपर्स से परिचित होना चाहिए। QNX में सभी परिचित कमांड, फ़ंक्शंस और ट्रिक्स भी हैं। उदाहरण के लिए, यह कमांड लाइन पर एक अनाम प्रोग्राम पाइप (पाइप) कैसे बनाया जाता है:

 # ls -l | less 

और एक नामित पाइप (FIFO) बनाने के लिए, आपको mkfifo कमांड या mkfifo() फ़ंक्शन का उपयोग करने की आवश्यकता है।

केवल एक विशेषता है। प्रोग्राम चैनलों के साथ काम करने के लिए QNX न्यूट्रिनो के लिए, आपको pipe मैनेजर चलाना होगा।

POSIX संदेश कतार

संदेश कतार नामित प्रोग्राम पाइप (FIFO) के समान हैं, लेकिन वे एक अधिक जटिल तंत्र हैं क्योंकि संदेश प्राथमिकता का समर्थन करें। QNX न्यूट्रिनो में POSIX संदेश कतारों के साथ काम करने के लिए, आपको mqueue मैनेजर चलाना होगा।

ध्यान दें कि QNX RTOS में संदेश कतारों में एक से अधिक स्लैश वर्ण '/' हो सकते हैं, जिसका अर्थ है कि आप निर्देशिका बना सकते हैं। इस प्रकार, POSIX मानक का विस्तार होता है, जिसके लिए आवश्यक है कि कतार नाम स्लैश से शुरू होता है और अब इस वर्ण में नहीं है। एक काफी सुविधाजनक सुविधा, जैसा कि आप एक निर्देशिका में एक सॉफ्टवेयर पैकेज या एक कंपनी की कतारों को समूहित कर सकते हैं।

साझा की गई स्मृति

क्यूएनएक्स न्यूट्रिनो में साझा मेमोरी के साथ काम अन्य यूनिक्स प्रणालियों की तरह ही है। चूँकि साझा मेमोरी मेकेनिज़्म को procnto प्रोसेस procnto में लागू किया जाता है, जिसमें माइक्रो कर्नेल भी होता है, आपको कुछ और चलाने की आवश्यकता नहीं होती है। आप shm_open() और mmap() फ़ंक्शन के लिए दस्तावेज़ में अधिक पढ़ सकते हैं।

अलग-अलग, यह ध्यान देने योग्य है कि साझा मेमोरी स्वयं अंतर-कार्य सहभागिता के लिए उपयुक्त नहीं है। यहां तक ​​कि अगर सर्वर केवल साझा मेमोरी के लिए लिखता है, और क्लाइंट केवल इससे पढ़ता है, तो ऐसा हो सकता है कि क्लाइंट आंशिक रूप से परिवर्तित डेटा पढ़ता है। ऐसी गलती बाद में पकड़ना मुश्किल हो सकता है, इसलिए बेहतर है कि इसे बिल्कुल न बनाएं। ऐसी स्थिति को बाहर करने के लिए, सिंक्रनाइज़ेशन प्राइमेटिक्स में से एक का उपयोग करना आवश्यक है, उदाहरण के लिए, म्यूटेक्स या सेमाफोर।

मैसेजिंग इंजन और शेयर्ड मेमोरी का उपयोग करते हुए कम इंटरेस्ट इंटर-टास्क इंटरेक्शन का तरीका है। यह विशेष रूप से उपयोगी है यदि आप एक वितरित प्रणाली बनाने की योजना बनाते हैं, जैसा कि साझा मेमोरी नेटवर्क पर उपलब्ध नहीं है। साझा स्मृति के उपयोग के कारण इस समाधान का प्रदर्शन बहुत अधिक है, और संदेश के माध्यम से सिंक्रनाइज़ करने और नेटवर्क पारदर्शिता की क्षमता भी है।

साझा मेमोरी का उपयोग करके किसी भी इंटरैक्शन को बनाने की कोशिश न करें, इस तथ्य के आधार पर कि यह सबसे तेज़ तरीका है। यदि सिंक्रोनाइज़ेशन प्राइमेटिव्स का उपयोग किया जाता है, तो गति मैसेजिंग इंजन की गति के बराबर हो सकती है। एक महत्वपूर्ण लाभ केवल एक बहुत बड़ी मात्रा के डेटा के आदान-प्रदान में होगा।

बनों का वादा किया

चूंकि मैंने वादा किया था कि बन्स होंगे, वे होंगे। मैं बिल्कुल नहीं भूली, और मुझे कोई आपत्ति नहीं है। पहला बान यह है कि संदेश भेजते समय, आप संदेश के लिए उसी बफर का उपयोग कर सकते हैं और उसका उत्तर दे सकते हैं। मैं यहां तक ​​कहूंगा कि वे इसे काफी बार करते हैं। इसे और अधिक सुविधाजनक बनाने के लिए, विभिन्न संदेशों और उनके जवाबों का वर्णन करने वाली सभी संरचनाओं को एक संघ में वर्गीकृत किया गया है। आमतौर पर, सर्वर से प्रतिक्रिया प्राप्त करने के बाद क्लाइंट को संदेश नहीं भेजा जाता है । इस प्रकार, आप बफर पर बचा सकते हैं।

दूसरा यह है कि QNX न्यूट्रिनो में POSIX फाइल डिस्क्रिप्टर कनेक्शन (संदेश भेजने के लिए) के समान है। और इसका मतलब यह है कि फ़ाइल डिस्क्रिप्टर ( write() , read() , आदि) का उपयोग करने वाले फ़ंक्शंस केवल निरर्थक ओवरहेड के साथ रैपर हैं जो सर्वर पर अपने तर्कों को संदेशों में परिवर्तित करते हैं। गंभीर गंभीर अनुकूलन। इसलिए, यदि आप QNX के लिए सिस्टम सॉफ़्टवेयर विकसित करना चाहते हैं, तो संसाधन प्रबंधक लिखना सीखें।

संदर्भ

1. वास्तविक समय ऑपरेटिंग सिस्टम QNX न्यूट्रिनो 6.3। सिस्टम आर्किटेक्चर। आईएसबीएन 5-94157-827-एक्स
2. वास्तविक समय ऑपरेटिंग सिस्टम QNX न्यूट्रिनो 6.3। उपयोगकर्ता मैनुअल। आईएसबीएन 978-5-9775-0370-9
3. रोब क्रेटेन, "क्यूएनएक्स न्यूट्रिनो का परिचय 2. रियल-टाइम एप्लिकेशन डेवलपर्स के लिए एक गाइड," दूसरा संस्करण। आईएसबीएन 978-5-9775-0681-6

---

¹ फ़ंक्शन MsgSend() और अन्य के नाम से उपसर्ग Msg केवल QNX Neutrino में दिखाई दिया, और QNX4 में इन फ़ंक्शन को बस Send() , Receive() और Reply() । इसलिए नाम SRR।

² उदाहरण में, डेटाबेस सर्वर और क्लाइंट सीधे मैसेजिंग फ़ंक्शन का उपयोग नहीं करते हैं, लेकिन हम पहले से ही जानते हैं कि QNX में, प्रत्येक read() , write() , sendto() , आदि के तहत SRR मेकेनिज्म छिपा है।

³ यदि सर्वर को केवल एक त्रुटि कोड वापस करना चाहिए, उदाहरण के लिए, यदि संदेश समर्थित नहीं है, तो MsgError() फ़ंक्शन का उपयोग करना अधिक सुविधाजनक है।

⁴ संसाधन प्रबंधकों का विवरण इस लेख के दायरे से परे है। यह संभव है कि मैं इसके बारे में कुछ और समय लिखूंगा।