യുണിക്സിൽ പൈപ്പ് ലൈനുകൾ എങ്ങനെയാണ് നടപ്പിലാക്കുന്നത്

ഈ ലേഖനം Unix കേർണലിൽ പൈപ്പ് ലൈനുകൾ നടപ്പിലാക്കുന്നതിനെ വിവരിക്കുന്നു. "എന്ന തലക്കെട്ടിൽ അടുത്തിടെ ഒരു ലേഖനം വന്നതിൽ ഞാൻ അൽപ്പം നിരാശനായിരുന്നു.എങ്ങനെയാണ് Unix-ൽ പൈപ്പ് ലൈനുകൾ പ്രവർത്തിക്കുന്നത്?"തിരിഞ്ഞു അല്ല ആന്തരിക ഘടനയെക്കുറിച്ച്. ഞാൻ ആകാംക്ഷാഭരിതനായി, ഉത്തരം കണ്ടെത്താൻ പഴയ ഉറവിടങ്ങളിൽ കുഴിച്ചു.

നമ്മൾ എന്തിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്?

പൈപ്പ് ലൈനുകൾ, "ഒരുപക്ഷേ യുണിക്സിലെ ഏറ്റവും പ്രധാനപ്പെട്ട കണ്ടുപിടുത്തം", ചെറിയ പ്രോഗ്രാമുകളെ ഒരുമിച്ച് ബന്ധിപ്പിക്കുന്നതിനുള്ള യുണിക്സ് തത്വശാസ്ത്രത്തിൻ്റെ നിർവചിക്കുന്ന സ്വഭാവവും കമാൻഡ് ലൈനിലെ പരിചിതമായ അടയാളവുമാണ്:

$ echo hello | wc -c
6

ഈ പ്രവർത്തനം കേർണൽ നൽകുന്ന സിസ്റ്റം കോളിനെ ആശ്രയിച്ചിരിക്കുന്നു pipe, ഇത് ഡോക്യുമെൻ്റേഷൻ പേജുകളിൽ വിവരിച്ചിരിക്കുന്നു പൈപ്പ് (7) и പൈപ്പ് (2):

ഇൻ്റർപ്രോസസ് കമ്മ്യൂണിക്കേഷനായി പൈപ്പ് ലൈനുകൾ ഒരു ഏകദിശ ചാനൽ നൽകുന്നു. പൈപ്പ്ലൈനിന് ഒരു ഇൻപുട്ടും (എഴുത്ത് അവസാനം) ഒരു ഔട്ട്പുട്ടും (റീഡ് എൻഡ്) ഉണ്ട്. പൈപ്പ്ലൈനിൻ്റെ ഇൻപുട്ടിലേക്ക് എഴുതിയ ഡാറ്റ ഔട്ട്പുട്ടിൽ വായിക്കാൻ കഴിയും.

കോൾ ഉപയോഗിച്ചാണ് പൈപ്പ്ലൈൻ സൃഷ്ടിക്കുന്നത് pipe(2), ഇത് രണ്ട് ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ നൽകുന്നു: ഒന്ന് പൈപ്പ് ലൈനിൻ്റെ ഇൻപുട്ടിനെ പരാമർശിക്കുന്നു, രണ്ടാമത്തേത് ഔട്ട്പുട്ടിലേക്ക്.

മുകളിലെ കമാൻഡിൽ നിന്നുള്ള ട്രെയ്സ് ഔട്ട്പുട്ട് പൈപ്പ്ലൈനിൻ്റെ സൃഷ്ടിയും അതിലൂടെ ഒരു പ്രക്രിയയിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ഡാറ്റയുടെ ഒഴുക്കും കാണിക്കുന്നു:

$ strace -qf -e execve,pipe,dup2,read,write 
    sh -c 'echo hello | wc -c'

execve("/bin/sh", ["sh", "-c", "echo hello | wc -c"], …)
pipe([3, 4])                            = 0
[pid 2604795] dup2(4, 1)                = 1
[pid 2604795] write(1, "hellon", 6)    = 6
[pid 2604796] dup2(3, 0)                = 0
[pid 2604796] execve("/usr/bin/wc", ["wc", "-c"], …)
[pid 2604796] read(0, "hellon", 16384) = 6
[pid 2604796] write(1, "6n", 2)        = 2

രക്ഷാകർതൃ പ്രക്രിയ വിളിക്കുന്നു pipe()മൌണ്ട് ചെയ്ത ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ ലഭിക്കാൻ. ഒരു ചൈൽഡ് പ്രോസസ്സ് ഒരു ഹാൻഡിലിലേക്ക് എഴുതുന്നു, മറ്റൊരു പ്രോസസ്സ് മറ്റൊരു ഹാൻഡിൽ നിന്ന് അതേ ഡാറ്റ വായിക്കുന്നു. stdin ഉം stdout ഉം പൊരുത്തപ്പെടുത്തുന്നതിന് 2, 3 ഡിസ്ക്രിപ്റ്ററുകൾ "പേരുമാറ്റാൻ" ഷെൽ dup4 ഉപയോഗിക്കുന്നു.

പൈപ്പുകൾ ഇല്ലെങ്കിൽ, ഫയലിൽ നിന്നുള്ള ഡാറ്റ വായിക്കാൻ ഷെൽ ഒരു പ്രക്രിയയുടെ ഫലം ഒരു ഫയലിലേക്ക് എഴുതുകയും മറ്റൊരു പ്രക്രിയയിലേക്ക് കൈമാറുകയും വേണം. തൽഫലമായി, ഞങ്ങൾ കൂടുതൽ വിഭവങ്ങളും ഡിസ്ക് സ്ഥലവും പാഴാക്കും. എന്നിരുന്നാലും, താൽക്കാലിക ഫയലുകളുടെ ഉപയോഗം ഒഴിവാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നതിനാൽ പൈപ്പ്ലൈനുകൾ നല്ലതാണ്:

ഒരു പ്രോസസ്സ് ശൂന്യമായ പൈപ്പ്ലൈനിൽ നിന്ന് വായിക്കാൻ ശ്രമിക്കുകയാണെങ്കിൽ read(2) ഡാറ്റ ലഭ്യമാകുന്നത് വരെ തടയും. ഒരു പ്രോസസ്സ് ഒരു മുഴുവൻ പൈപ്പ്ലൈനിലേക്ക് എഴുതാൻ ശ്രമിക്കുകയാണെങ്കിൽ, പിന്നെ write(2) പൈപ്പ് ലൈനിൽ നിന്ന് എഴുത്ത് നടത്തുന്നതിന് ആവശ്യമായ ഡാറ്റ വായിക്കുന്നത് വരെ തടയും.

POSIX ആവശ്യകത പോലെ, ഇത് ഒരു പ്രധാന സ്വത്താണ്: വരെ പൈപ്പ്ലൈനിലേക്ക് എഴുതുക PIPE_BUF ബൈറ്റുകൾ (കുറഞ്ഞത് 512) ആറ്റോമിക് ആയിരിക്കണം, അതിനാൽ സാധാരണ ഫയലുകൾക്ക് (അത്തരം ഗ്യാരൻ്റി നൽകാത്ത) പ്രക്രിയകൾക്ക് പൈപ്പ് ലൈനിലൂടെ പരസ്പരം ആശയവിനിമയം നടത്താൻ കഴിയും.

ഒരു സാധാരണ ഫയൽ ഉപയോഗിക്കുമ്പോൾ, ഒരു പ്രോസസ്സിന് അതിൻ്റെ എല്ലാ ഔട്ട്പുട്ടും അതിലേക്ക് എഴുതി മറ്റൊരു പ്രക്രിയയിലേക്ക് കൈമാറാൻ കഴിയും. അല്ലെങ്കിൽ ഒരു എഴുത്ത് അല്ലെങ്കിൽ വായന പൂർത്തിയാകുമ്പോൾ പരസ്പരം അറിയിക്കുന്നതിന് ബാഹ്യ സിഗ്നലിംഗ് സംവിധാനം (സെമാഫോർ പോലെ) ഉപയോഗിച്ച് പ്രക്രിയകൾക്ക് വളരെ സമാന്തര മോഡിൽ പ്രവർത്തിക്കാൻ കഴിയും. കൺവെയറുകൾ ഈ കുഴപ്പങ്ങളിൽ നിന്ന് നമ്മെ രക്ഷിക്കുന്നു.

നമ്മൾ എന്താണ് അന്വേഷിക്കുന്നത്?

ഒരു കൺവെയർ എങ്ങനെ പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾക്ക് സങ്കൽപ്പിക്കാൻ എളുപ്പമുള്ള തരത്തിൽ ഞാൻ ഇത് ലളിതമായി വിശദീകരിക്കും. നിങ്ങൾ ഒരു ബഫറും മെമ്മറിയിൽ കുറച്ച് അവസ്ഥയും അനുവദിക്കേണ്ടതുണ്ട്. ബഫറിൽ നിന്ന് ഡാറ്റ ചേർക്കാനും നീക്കം ചെയ്യാനും നിങ്ങൾക്ക് ഫംഗ്ഷനുകൾ ആവശ്യമാണ്. ഫയൽ ഡിസ്ക്രിപ്റ്ററുകളിലെ റീഡ് ആൻഡ് റൈറ്റ് ഓപ്പറേഷനുകളിൽ ഫംഗ്ഷനുകൾ വിളിക്കാൻ നിങ്ങൾക്ക് ചില മാർഗങ്ങൾ ആവശ്യമാണ്. മുകളിൽ വിവരിച്ച പ്രത്യേക സ്വഭാവം നടപ്പിലാക്കാൻ നിങ്ങൾക്ക് ലോക്കുകൾ ആവശ്യമാണ്.

ഞങ്ങളുടെ അവ്യക്തമായ മാനസിക മാതൃക സ്ഥിരീകരിക്കുന്നതിനോ നിരസിക്കുന്നതിനോ പ്രകാശമുള്ള വിളക്കിന് കീഴിൽ കേർണൽ സോഴ്സ് കോഡ് ചോദ്യം ചെയ്യാൻ ഞങ്ങൾ ഇപ്പോൾ തയ്യാറാണ്. എന്നാൽ അപ്രതീക്ഷിതമായ കാര്യങ്ങൾക്കായി എപ്പോഴും തയ്യാറാകുക.

നമ്മൾ എവിടെയാണ് നോക്കുന്നത്?

പ്രശസ്ത പുസ്തകത്തിൻ്റെ എൻ്റെ കോപ്പി എവിടെയാണെന്ന് എനിക്കറിയില്ല "ലയൺസ് ബുക്ക്"യുണിക്സ് 6 സോഴ്സ് കോഡിനൊപ്പം, പക്ഷേ നന്ദി യുണിക്സ് ഹെറിറ്റേജ് സൊസൈറ്റി നിങ്ങൾക്ക് ഓൺലൈനിൽ തിരയാൻ കഴിയും സോഴ്സ് കോഡ് Unix-ൻ്റെ പഴയ പതിപ്പുകൾ.

TUHS ആർക്കൈവിലൂടെ അലഞ്ഞുതിരിയുന്നത് ഒരു മ്യൂസിയം സന്ദർശിക്കുന്നത് പോലെയാണ്. ഞങ്ങൾക്ക് ഞങ്ങളുടെ പങ്കിട്ട ചരിത്രം നോക്കാം, പഴയ ടേപ്പുകളിൽ നിന്നും പ്രിൻ്റുകളിൽ നിന്നും ഈ മെറ്റീരിയലെല്ലാം ഓരോന്നായി വീണ്ടെടുക്കാനുള്ള നിരവധി വർഷത്തെ പരിശ്രമത്തോട് എനിക്ക് ബഹുമാനമുണ്ട്. ഇപ്പോഴും കാണാതായ ആ ശകലങ്ങളെക്കുറിച്ച് എനിക്ക് നന്നായി അറിയാം.

കൺവെയറുകളുടെ പുരാതന ചരിത്രത്തെക്കുറിച്ചുള്ള നമ്മുടെ ജിജ്ഞാസയെ തൃപ്തിപ്പെടുത്തിയ ശേഷം, താരതമ്യത്തിനായി നമുക്ക് ആധുനിക കേർണലുകളിലേക്ക് നോക്കാം.

വഴിയിൽ, pipe പട്ടികയിലെ സിസ്റ്റം കോൾ നമ്പർ 42 ആണ് sysent[]. യാദൃശ്ചികമാണോ?

പരമ്പരാഗത യുണിക്സ് കേർണലുകൾ (1970–1974)

ഞാൻ അടയാളങ്ങളൊന്നും കണ്ടെത്തിയില്ല pipe(2) അകത്തുമില്ല PDP-7 Unix (ജനുവരി 1970), അല്ലെങ്കിൽ ഇൻ Unix-ൻ്റെ ആദ്യ പതിപ്പ് (നവംബർ 1971), അല്ലെങ്കിൽ അപൂർണ്ണമായ സോഴ്സ് കോഡിലോ രണ്ടാം പതിപ്പ് (ജൂൺ 1972).

TUHS പറയുന്നു യുണിക്സിൻ്റെ മൂന്നാം പതിപ്പ് (ഫെബ്രുവരി 1973) കൺവെയറുകളുള്ള ആദ്യ പതിപ്പായി:

അസംബ്ലി ഭാഷയിൽ എഴുതിയ കേർണലുള്ള അവസാന പതിപ്പായിരുന്നു Unix 1973rd പതിപ്പ്, മാത്രമല്ല പൈപ്പ് ലൈനുകളുള്ള ആദ്യ പതിപ്പും. XNUMX-ൽ, മൂന്നാം പതിപ്പ് മെച്ചപ്പെടുത്തുന്നതിനുള്ള പ്രവർത്തനങ്ങൾ നടന്നു, കേർണൽ C-യിൽ മാറ്റിയെഴുതി, അങ്ങനെ Unix-ൻ്റെ നാലാമത്തെ പതിപ്പ് പ്രത്യക്ഷപ്പെട്ടു.

ഒരു വായനക്കാരൻ ഒരു ഡോക്യുമെൻ്റിൻ്റെ സ്കാൻ കണ്ടെത്തി, അതിൽ "ഒരു ഗാർഡൻ ഹോസ് പോലെയുള്ള പ്രോഗ്രാമുകൾ ബന്ധിപ്പിക്കുക" എന്ന ആശയം ഡഗ് മക്കിൾറോയ് നിർദ്ദേശിച്ചു.

ബ്രയാൻ കെർനിഗൻ്റെ പുസ്തകത്തിൽയുണിക്സ്: ഒരു ചരിത്രവും ഒരു ഓർമ്മക്കുറിപ്പും", കൺവെയറുകളുടെ ആവിർഭാവത്തിൻ്റെ ചരിത്രത്തിൽ, ഈ രേഖയും പരാമർശിക്കപ്പെടുന്നു: "... ഇത് 30 വർഷമായി ബെൽ ലാബിലെ എൻ്റെ ഓഫീസിലെ ചുമരിൽ തൂക്കിയിട്ടിരിക്കുന്നു." ഇവിടെ മക്‌ലോറോയുമായുള്ള അഭിമുഖം, കൂടാതെ മറ്റൊരു കഥ 2014-ൽ എഴുതിയ മക്‌ലോയ്‌യുടെ കൃതി:

Unix പുറത്തിറങ്ങിയപ്പോൾ, coroutines-നോടുള്ള എൻ്റെ ആകർഷണം, OS-ൻ്റെ രചയിതാവായ കെൻ തോംപ്‌സണോട് ഒരു പ്രോസസ്സിൽ എഴുതിയ ഡാറ്റ ഉപകരണത്തിലേക്ക് മാത്രമല്ല, മറ്റൊരു പ്രോസസ്സിലേക്ക് ഔട്ട്‌പുട്ട് ചെയ്യാനും അനുവദിക്കണമെന്ന് ആവശ്യപ്പെടാൻ എന്നെ പ്രേരിപ്പിച്ചു. അത് സാധ്യമാണെന്ന് കെൻ തീരുമാനിച്ചു. എന്നിരുന്നാലും, ഒരു മിനിമലിസ്റ്റ് എന്ന നിലയിൽ, എല്ലാ സിസ്റ്റം പ്രവർത്തനങ്ങളും ഒരു പ്രധാന പങ്ക് വഹിക്കണമെന്ന് അദ്ദേഹം ആഗ്രഹിച്ചു. പ്രോസസ്സുകൾക്കിടയിൽ നേരിട്ട് എഴുതുന്നത് ഒരു ഇൻ്റർമീഡിയറ്റ് ഫയലിലേക്ക് എഴുതുന്നതിനേക്കാൾ വലിയ നേട്ടമാണോ? “പൈപ്പ്‌ലൈൻ” എന്ന ആകർഷകമായ പേരും പ്രക്രിയകൾ തമ്മിലുള്ള ആശയവിനിമയത്തിനുള്ള വാക്യഘടനയുടെ വിവരണവും ഉപയോഗിച്ച് ഞാൻ ഒരു നിർദ്ദിഷ്ട നിർദ്ദേശം നൽകിയപ്പോൾ മാത്രമാണ് കെൻ ഒടുവിൽ ആക്രോശിച്ചത്: “ഞാൻ അത് ചെയ്യും!”

ചെയ്തു. നിർഭാഗ്യകരമായ ഒരു സായാഹ്നം, കെൻ കേർണലും ഷെല്ലും മാറ്റി, ഇൻപുട്ട് എങ്ങനെ സ്വീകരിച്ചു (ഒരു പൈപ്പ്ലൈനിൽ നിന്ന് വരാം) സ്റ്റാൻഡേർഡ് ചെയ്യാൻ നിരവധി സ്റ്റാൻഡേർഡ് പ്രോഗ്രാമുകൾ നിശ്ചയിച്ചു, കൂടാതെ ഫയലുകളുടെ പേരുകളും മാറ്റി. അടുത്ത ദിവസം, പൈപ്പ്ലൈനുകൾ ആപ്ലിക്കേഷനുകളിൽ വളരെ വ്യാപകമായി ഉപയോഗിക്കാൻ തുടങ്ങി. ആഴ്‌ചയുടെ അവസാനത്തോടെ, വേഡ് പ്രോസസറുകളിൽ നിന്ന് പ്രിൻ്ററിലേക്ക് പ്രമാണങ്ങൾ അയയ്ക്കാൻ സെക്രട്ടറിമാർ അവരെ ഉപയോഗിച്ചു. കുറച്ച് കഴിഞ്ഞ്, പൈപ്പ് ലൈനുകളുടെ ഉപയോഗം ക്ലീനർ കൺവെൻഷനുകൾ ഉപയോഗിച്ച് പൊതിയുന്നതിനായി കെൻ യഥാർത്ഥ API, വാക്യഘടന എന്നിവ മാറ്റിസ്ഥാപിച്ചു, അത് അന്നുമുതൽ ഉപയോഗിച്ചുവരുന്നു.

നിർഭാഗ്യവശാൽ, യുണിക്സ് കേർണലിൻ്റെ മൂന്നാം പതിപ്പിൻ്റെ സോഴ്സ് കോഡ് നഷ്ടപ്പെട്ടു. കേർണൽ സോഴ്‌സ് കോഡ് സിയിൽ എഴുതിയിട്ടുണ്ടെങ്കിലും നാലാം പതിപ്പ്, 1973 നവംബറിൽ പുറത്തിറങ്ങി, പക്ഷേ ഔദ്യോഗിക റിലീസിന് ഏതാനും മാസങ്ങൾക്കുമുമ്പ് ഇത് പുറത്തുവന്നു, പൈപ്പ് ലൈൻ നടപ്പാക്കലുകൾ അടങ്ങിയിട്ടില്ല. ഈ ഐതിഹാസികമായ Unix ഫംഗ്‌ഷൻ്റെ സോഴ്‌സ് കോഡ് നഷ്‌ടമായത് ലജ്ജാകരമാണ്, ഒരുപക്ഷേ എന്നെന്നേക്കുമായി.

ഞങ്ങൾക്ക് ടെക്സ്റ്റ് ഡോക്യുമെൻ്റേഷൻ ഉണ്ട് pipe(2) രണ്ട് റിലീസുകളിൽ നിന്നും, അതിനാൽ നിങ്ങൾക്ക് ഡോക്യുമെൻ്റേഷൻ തിരയുന്നതിലൂടെ ആരംഭിക്കാം മൂന്നാം പതിപ്പ് (ചില വാക്കുകൾക്ക്, "മാനുവലായി" അടിവരയിട്ടിരിക്കുന്നു, അക്ഷരങ്ങളുടെ ^H എന്നതിൻ്റെ ഒരു സ്ട്രിംഗ്, തുടർന്ന് ഒരു അടിവര!). ഈ പ്രോട്ടോ-pipe(2) അസംബ്ലി ഭാഷയിൽ എഴുതുകയും ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്റർ മാത്രം നൽകുകയും ചെയ്യുന്നു, പക്ഷേ ഇതിനകം പ്രതീക്ഷിക്കുന്ന അടിസ്ഥാന പ്രവർത്തനം നൽകുന്നു:

സിസ്റ്റം കോൾ പൈപ്പ് പൈപ്പ് ലൈൻ എന്ന് വിളിക്കുന്ന ഒരു ഇൻപുട്ട്/ഔട്ട്പുട്ട് മെക്കാനിസം സൃഷ്ടിക്കുന്നു. റിട്ടേൺ ഫയൽ ഡിസ്ക്രിപ്റ്റർ റീഡ് ആൻഡ് റൈറ്റ് ഓപ്പറേഷനുകൾക്കായി ഉപയോഗിക്കാം. പൈപ്പ്ലൈനിലേക്ക് എന്തെങ്കിലും എഴുതുമ്പോൾ, 504 ബൈറ്റുകൾ വരെ ഡാറ്റ ബഫർ ചെയ്യപ്പെടും, അതിനുശേഷം എഴുത്ത് പ്രക്രിയ താൽക്കാലികമായി നിർത്തിവയ്ക്കുന്നു. പൈപ്പ്ലൈനിൽ നിന്ന് വായിക്കുമ്പോൾ, ബഫർ ചെയ്ത ഡാറ്റ എടുത്തുകളയുന്നു.

അടുത്ത വർഷം ആയപ്പോഴേക്കും കേർണൽ C-യിൽ വീണ്ടും എഴുതപ്പെട്ടു പൈപ്പ് (2) നാലാം പതിപ്പിൽ പ്രോട്ടോടൈപ്പ് ഉപയോഗിച്ച് അതിൻ്റെ ആധുനിക രൂപം സ്വന്തമാക്കി "pipe(fildes)"

സിസ്റ്റം കോൾ പൈപ്പ് പൈപ്പ് ലൈൻ എന്ന് വിളിക്കുന്ന ഒരു ഇൻപുട്ട്/ഔട്ട്പുട്ട് മെക്കാനിസം സൃഷ്ടിക്കുന്നു. റിട്ടേൺ ചെയ്ത ഫയൽ ഡിസ്ക്രിപ്റ്ററുകൾ റീഡ് ആൻഡ് റൈറ്റ് ഓപ്പറേഷനുകളിൽ ഉപയോഗിക്കാം. പൈപ്പ്‌ലൈനിൽ എന്തെങ്കിലും എഴുതുമ്പോൾ, r1 (resp. fildes[1])-ൽ തിരികെ ലഭിക്കുന്ന ഹാൻഡിൽ ഉപയോഗിക്കുന്നു, 4096 ബൈറ്റുകളുടെ ഡാറ്റയിലേക്ക് ബഫർ ചെയ്യുന്നു, അതിനുശേഷം എഴുത്ത് പ്രക്രിയ താൽക്കാലികമായി നിർത്തിവയ്ക്കുന്നു. പൈപ്പ്ലൈനിൽ നിന്ന് വായിക്കുമ്പോൾ, ഹാൻഡിൽ r0 (resp. fildes[0]) ലേക്ക് മടങ്ങുന്നു, ഡാറ്റ എടുക്കുന്നു.

ഒരു പൈപ്പ് ലൈൻ നിർവചിച്ചുകഴിഞ്ഞാൽ, രണ്ട് (അല്ലെങ്കിൽ അതിലധികമോ) ആശയവിനിമയ പ്രക്രിയകൾ (തുടർന്നുള്ള കോളുകൾ വഴി സൃഷ്ടിക്കപ്പെടുന്നു. ഫോർക്ക്) കോളുകൾ ഉപയോഗിച്ച് പൈപ്പ്ലൈനിൽ നിന്ന് ഡാറ്റ കൈമാറും വായിക്കുക и എഴുതുക.

ഒരു പൈപ്പ് ലൈൻ വഴി ബന്ധിപ്പിച്ചിരിക്കുന്ന പ്രക്രിയകളുടെ ഒരു രേഖീയ ശ്രേണിയെ നിർവചിക്കുന്നതിന് ഷെല്ലിന് ഒരു വാക്യഘടനയുണ്ട്.

ഒരു അറ്റം മാത്രമുള്ള (എല്ലാ റൈറ്റിംഗ് ഫയൽ ഡിസ്ക്രിപ്റ്ററുകളും അടച്ചിരിക്കുന്നു) ശൂന്യമായ പൈപ്പ്ലൈനിൽ നിന്ന് വായിക്കാനുള്ള കോളുകൾ "ഫയലിൻ്റെ അവസാനം" തിരികെ നൽകുന്നു. സമാനമായ സാഹചര്യത്തിൽ എഴുതാനുള്ള കോളുകൾ അവഗണിക്കപ്പെടുന്നു.

ഏറ്റവും നേരത്തെ സംരക്ഷിത പൈപ്പ്ലൈൻ നടപ്പിലാക്കൽ ബന്ധപ്പെട്ടിരിക്കുന്നു യുണിക്സിൻ്റെ അഞ്ചാം പതിപ്പിലേക്ക് (ജൂൺ 1974), എന്നാൽ ഇത് അടുത്ത റിലീസിൽ പ്രത്യക്ഷപ്പെട്ടതിന് ഏതാണ്ട് സമാനമാണ്. അഭിപ്രായങ്ങൾ ചേർത്തു, അതിനാൽ നിങ്ങൾക്ക് അഞ്ചാം പതിപ്പ് ഒഴിവാക്കാം.

യുണിക്സിൻ്റെ ആറാം പതിപ്പ് (1975)

നമുക്ക് Unix സോഴ്സ് കോഡ് വായിക്കാൻ തുടങ്ങാം ആറാം പതിപ്പ് (മേയ് 1975). വലിയതോതിൽ നന്ദി ലയൺസ് മുമ്പത്തെ പതിപ്പുകളുടെ ഉറവിടങ്ങളേക്കാൾ കണ്ടെത്തുന്നത് വളരെ എളുപ്പമാണ്:

വർഷങ്ങളോളം പുസ്തകം ലയൺസ് ബെൽ ലാബ്സിന് പുറത്ത് ലഭ്യമായ യുണിക്സ് കേർണലിലെ ഏക രേഖയായിരുന്നു ഇത്. ആറാം പതിപ്പ് ലൈസൻസ് അതിൻ്റെ സോഴ്സ് കോഡ് ഉപയോഗിക്കാൻ അധ്യാപകരെ അനുവദിച്ചെങ്കിലും, ഏഴാം പതിപ്പ് ലൈസൻസ് ഈ സാധ്യത ഒഴിവാക്കിയതിനാൽ, പുസ്തകം നിയമവിരുദ്ധമായി ടൈപ്പ് ചെയ്ത പകർപ്പുകളുടെ രൂപത്തിൽ വിതരണം ചെയ്തു.

ഇന്ന് നിങ്ങൾക്ക് പുസ്തകത്തിൻ്റെ ഒരു റീപ്രിൻ്റ് വാങ്ങാം, അതിൻ്റെ കവർ കോപ്പി മെഷീനിൽ വിദ്യാർത്ഥികളെ കാണിക്കുന്നു. വാറൻ ടൂമിക്ക് നന്ദി (TUHS പ്രോജക്റ്റ് ആരംഭിച്ചത്) നിങ്ങൾക്ക് ഡൗൺലോഡ് ചെയ്യാം ആറാം പതിപ്പിനുള്ള സോഴ്സ് കോഡുള്ള PDF ഫയൽ. ഫയൽ സൃഷ്‌ടിക്കുന്നതിന് എത്രമാത്രം പരിശ്രമിച്ചു എന്നതിൻ്റെ ഒരു ആശയം നിങ്ങൾക്ക് നൽകാൻ ഞാൻ ആഗ്രഹിക്കുന്നു:

15 വർഷത്തിലേറെ മുമ്പ്, നൽകിയിരിക്കുന്ന സോഴ്സ് കോഡിൻ്റെ ഒരു പകർപ്പ് ഞാൻ ടൈപ്പ് ചെയ്തു ലയൺസ്, കാരണം അജ്ഞാതമായ മറ്റ് പകർപ്പുകളിൽ നിന്നുള്ള എൻ്റെ പകർപ്പിൻ്റെ ഗുണനിലവാരം എനിക്ക് ഇഷ്ടപ്പെട്ടില്ല. TUHS ഇതുവരെ നിലവിലില്ല, എനിക്ക് പഴയ ഉറവിടങ്ങളിലേക്ക് ആക്‌സസ് ഇല്ലായിരുന്നു. എന്നാൽ 1988-ൽ, ഒരു PDP9 കമ്പ്യൂട്ടറിൽ നിന്നുള്ള ബാക്കപ്പ് അടങ്ങിയ ഒരു പഴയ 11-ട്രാക്ക് ടേപ്പ് ഞാൻ കണ്ടെത്തി. ഇത് പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പറയാൻ പ്രയാസമാണ്, പക്ഷേ ഒരു കേടുപാടുകൾ കൂടാതെ /usr/src/ ട്രീ ഉണ്ടായിരുന്നു, അതിൽ ഭൂരിഭാഗം ഫയലുകളും 1979 എന്ന് ലേബൽ ചെയ്തിരിക്കുന്നു, അത് അപ്പോഴും പുരാതനമായി തോന്നി. ഞാൻ വിശ്വസിച്ചതുപോലെ അത് ഏഴാം പതിപ്പ് അല്ലെങ്കിൽ അതിൻ്റെ ഡെറിവേറ്റീവ് PWB ആയിരുന്നു.

ഞാൻ കണ്ടെത്തൽ ഒരു അടിസ്ഥാനമായി എടുക്കുകയും ആറാം പതിപ്പിലേക്ക് ഉറവിടങ്ങൾ സ്വമേധയാ എഡിറ്റ് ചെയ്യുകയും ചെയ്തു. ചില കോഡുകൾ അതേപടി തുടർന്നു, എന്നാൽ ചിലത് ചെറുതായി എഡിറ്റ് ചെയ്യേണ്ടി വന്നു, ആധുനിക += ടോക്കൺ കാലഹരണപ്പെട്ട =+ ആക്കി മാറ്റി. ചില കാര്യങ്ങൾ ലളിതമായി ഇല്ലാതാക്കി, ചിലത് പൂർണ്ണമായും മാറ്റിയെഴുതേണ്ടതായി വന്നു, പക്ഷേ വളരെയധികം അല്ല.

ഇന്ന് നമുക്ക് TUHS-ൽ നിന്ന് ആറാം പതിപ്പിൻ്റെ സോഴ്സ് കോഡ് ഓൺലൈനായി വായിക്കാം ആർക്കൈവ്, ഡെന്നിസ് റിച്ചിക്ക് ഒരു കൈ ഉണ്ടായിരുന്നു.

വഴിയിൽ, ഒറ്റനോട്ടത്തിൽ, കെർനിഗൻ്റെയും റിച്ചിയുടെയും കാലഘട്ടത്തിന് മുമ്പുള്ള സി-കോഡിൻ്റെ പ്രധാന സവിശേഷതയാണ് സംക്ഷിപ്തത. എൻ്റെ സൈറ്റിലെ താരതമ്യേന ഇടുങ്ങിയ ഡിസ്പ്ലേ ഏരിയയ്ക്ക് അനുയോജ്യമായ രീതിയിൽ വിപുലമായ എഡിറ്റിംഗ് കൂടാതെ കോഡിൻ്റെ ഭാഗങ്ങൾ ചേർക്കാൻ എനിക്ക് പലപ്പോഴും സാധിക്കാറില്ല.

തുടക്കത്തിൽ /usr/sys/ken/pipe.c ഒരു വിശദീകരണ കമൻ്റ് ഉണ്ട് (അതെ, കൂടുതൽ ഉണ്ട് /usr/sys/dmr):

/*
 * Max allowable buffering per pipe.
 * This is also the max size of the
 * file created to implement the pipe.
 * If this size is bigger than 4096,
 * pipes will be implemented in LARG
 * files, which is probably not good.
 */
#define    PIPSIZ    4096

നാലാം പതിപ്പിന് ശേഷം ബഫർ വലുപ്പം മാറിയിട്ടില്ല. എന്നാൽ ഇവിടെ നമ്മൾ കാണുന്നത്, പൊതു ഡോക്യുമെൻ്റേഷൻ ഇല്ലാതെ, പൈപ്പ് ലൈനുകൾ ഒരിക്കൽ ഫയലുകൾ ബാക്കപ്പ് സ്റ്റോറേജായി ഉപയോഗിച്ചിരുന്നു എന്നാണ്!

LARG ഫയലുകളെ സംബന്ധിച്ചിടത്തോളം, അവ യോജിക്കുന്നു ഇനോഡ് ഫ്ലാഗ് LARG, ഇത് പ്രോസസ്സ് ചെയ്യാൻ "വലിയ അഡ്രസിംഗ് അൽഗോരിതം" ഉപയോഗിക്കുന്നു പരോക്ഷ ബ്ലോക്കുകൾ വലിയ ഫയൽ സിസ്റ്റങ്ങളെ പിന്തുണയ്ക്കാൻ. അവ ഉപയോഗിക്കാതിരിക്കുന്നതാണ് നല്ലതെന്ന് കെൻ പറഞ്ഞതിനാൽ, അദ്ദേഹത്തിൻ്റെ വാക്ക് ഞാൻ സന്തോഷത്തോടെ സ്വീകരിക്കും.

യഥാർത്ഥ സിസ്റ്റം കോൾ ഇതാ pipe:

/*
 * The sys-pipe entry.
 * Allocate an inode on the root device.
 * Allocate 2 file structures.
 * Put it all together with flags.
 */
pipe()
{
    register *ip, *rf, *wf;
    int r;

    ip = ialloc(rootdev);
    if(ip == NULL)
        return;
    rf = falloc();
    if(rf == NULL) {
        iput(ip);
        return;
    }
    r = u.u_ar0[R0];
    wf = falloc();
    if(wf == NULL) {
        rf->f_count = 0;
        u.u_ofile[r] = NULL;
        iput(ip);
        return;
    }
    u.u_ar0[R1] = u.u_ar0[R0]; /* wf's fd */
    u.u_ar0[R0] = r;           /* rf's fd */
    wf->f_flag = FWRITE|FPIPE;
    wf->f_inode = ip;
    rf->f_flag = FREAD|FPIPE;
    rf->f_inode = ip;
    ip->i_count = 2;
    ip->i_flag = IACC|IUPD;
    ip->i_mode = IALLOC;
}

ഇവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് കമൻ്റ് വ്യക്തമായി വിവരിക്കുന്നു. എന്നാൽ കോഡ് മനസ്സിലാക്കുന്നത് അത്ര എളുപ്പമല്ല, ഭാഗികമായി കാരണം "struct user u» കൂടാതെ രജിസ്റ്ററുകളും R0 и R1 സിസ്റ്റം കോൾ പാരാമീറ്ററുകളും റിട്ടേൺ മൂല്യങ്ങളും കടന്നുപോയി.

കൂടെ ശ്രമിക്കാം ialloc() ഡിസ്കിൽ ഇട്ടു ഐനോഡ് (ഇൻഡക്സ് ഹാൻഡിൽ), ഒപ്പം സഹായത്തോടെ ഫാലോക്ക്() - രണ്ടെണ്ണം ഓർമ്മയിൽ വയ്ക്കുക ഫയൽ. എല്ലാം ശരിയാണെങ്കിൽ, ഈ ഫയലുകളെ പൈപ്പ്ലൈനിൻ്റെ രണ്ട് അറ്റങ്ങളായി തിരിച്ചറിയാൻ ഞങ്ങൾ ഫ്ലാഗുകൾ സജ്ജീകരിക്കും, അവയെ അതേ ഐനോഡിലേക്ക് പോയിൻ്റ് ചെയ്യുക (അതിൻ്റെ റഫറൻസ് എണ്ണം 2 ആയി സജ്ജീകരിക്കും), കൂടാതെ ഐനോഡ് പരിഷ്കരിച്ചതും ഉപയോഗത്തിലുള്ളതുമാണെന്ന് അടയാളപ്പെടുത്തും. അഭ്യർത്ഥനകൾ ശ്രദ്ധിക്കുക iput() പുതിയ ഐനോഡിലെ റഫറൻസ് എണ്ണം കുറയ്ക്കുന്നതിനുള്ള പിശക് പാതകളിൽ.

pipe() കടന്നു വേണം R0 и R1 വായിക്കാനും എഴുതാനും ഫയൽ ഡിസ്ക്രിപ്റ്റർ നമ്പറുകൾ തിരികെ നൽകുക. falloc() ഫയൽ ഘടനയിലേക്ക് ഒരു പോയിൻ്റർ നൽകുന്നു, മാത്രമല്ല വഴി "മടങ്ങുന്നു" u.u_ar0[R0] ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്ററും. അതായത്, കോഡ് സംരക്ഷിക്കുന്നു r വായിക്കുന്നതിനുള്ള ഫയൽ ഡിസ്ക്രിപ്റ്റർ കൂടാതെ നേരിട്ട് എഴുതാൻ ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്റർ നൽകുന്നു u.u_ar0[R0] രണ്ടാമത്തെ കോളിന് ശേഷം falloc().

ഫ്ലാഗ് FPIPE, പൈപ്പ്ലൈൻ സൃഷ്ടിക്കുമ്പോൾ ഞങ്ങൾ സജ്ജമാക്കുന്നത്, ഫംഗ്ഷൻ്റെ സ്വഭാവത്തെ നിയന്ത്രിക്കുന്നു rdwr() in sys2.cനിർദ്ദിഷ്ട I/O ദിനചര്യകൾ വിളിക്കുന്നു:

/*
 * common code for read and write calls:
 * check permissions, set base, count, and offset,
 * and switch out to readi, writei, or pipe code.
 */
rdwr(mode)
{
    register *fp, m;

    m = mode;
    fp = getf(u.u_ar0[R0]);
        /* … */

    if(fp->f_flag&FPIPE) {
        if(m==FREAD)
            readp(fp); else
            writep(fp);
    }
        /* … */
}

തുടർന്ന് ചടങ്ങ് readp() в pipe.c പൈപ്പ്ലൈനിൽ നിന്നുള്ള ഡാറ്റ വായിക്കുന്നു. എന്നാൽ നടപ്പിലാക്കൽ ആരംഭിക്കുന്നത് കണ്ടെത്തുന്നതാണ് നല്ലത് writep(). വീണ്ടും, പാസിംഗ് ആർഗ്യുമെൻ്റുകളുടെ കൺവെൻഷനുകൾ കാരണം കോഡ് കൂടുതൽ സങ്കീർണ്ണമായിരിക്കുന്നു, എന്നാൽ ചില വിശദാംശങ്ങൾ ഒഴിവാക്കാവുന്നതാണ്.

writep(fp)
{
    register *rp, *ip, c;

    rp = fp;
    ip = rp->f_inode;
    c = u.u_count;

loop:
    /* If all done, return. */

    plock(ip);
    if(c == 0) {
        prele(ip);
        u.u_count = 0;
        return;
    }

    /*
     * If there are not both read and write sides of the
     * pipe active, return error and signal too.
     */

    if(ip->i_count < 2) {
        prele(ip);
        u.u_error = EPIPE;
        psignal(u.u_procp, SIGPIPE);
        return;
    }

    /*
     * If the pipe is full, wait for reads to deplete
     * and truncate it.
     */

    if(ip->i_size1 == PIPSIZ) {
        ip->i_mode =| IWRITE;
        prele(ip);
        sleep(ip+1, PPIPE);
        goto loop;
    }

    /* Write what is possible and loop back. */

    u.u_offset[0] = 0;
    u.u_offset[1] = ip->i_size1;
    u.u_count = min(c, PIPSIZ-u.u_offset[1]);
    c =- u.u_count;
    writei(ip);
    prele(ip);
    if(ip->i_mode&IREAD) {
        ip->i_mode =& ~IREAD;
        wakeup(ip+2);
    }
    goto loop;
}

പൈപ്പ്ലൈൻ ഇൻപുട്ടിലേക്ക് ബൈറ്റുകൾ എഴുതാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു u.u_count. ആദ്യം നമ്മൾ ഐനോഡ് ലോക്ക് ചെയ്യണം (ചുവടെ കാണുക plock/prele).

തുടർന്ന് ഞങ്ങൾ ഐനോഡ് റഫറൻസ് കൗണ്ടർ പരിശോധിക്കുന്നു. പൈപ്പ്ലൈനിൻ്റെ രണ്ടറ്റവും തുറന്നിരിക്കുന്നിടത്തോളം, കൌണ്ടർ 2 ന് തുല്യമായിരിക്കണം. ഞങ്ങൾ ഒരു ലിങ്ക് പിടിക്കുന്നു (ഇതിൽ നിന്ന് rp->f_inode), അതിനാൽ കൌണ്ടർ 2-ൽ കുറവാണെങ്കിൽ, വായനാ പ്രക്രിയ പൈപ്പ്ലൈനിൻ്റെ അവസാനം അടച്ചുവെന്ന് അർത്ഥമാക്കണം. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഞങ്ങൾ അടച്ച പൈപ്പ്ലൈനിലേക്ക് എഴുതാൻ ശ്രമിക്കുന്നു, ഇത് ഒരു പിശകാണ്. ആദ്യ തവണ പിശക് കോഡ് EPIPE സിഗ്നലും SIGPIPE യുണിക്സിൻ്റെ ആറാം പതിപ്പിൽ പ്രത്യക്ഷപ്പെട്ടു.

എന്നാൽ കൺവെയർ തുറന്നാലും നിറഞ്ഞിരിക്കാം. ഈ സാഹചര്യത്തിൽ, പൈപ്പ്ലൈനിൽ നിന്ന് മറ്റൊരു പ്രക്രിയ വായിക്കുകയും അതിൽ മതിയായ ഇടം സ്വതന്ത്രമാക്കുകയും ചെയ്യുമെന്ന പ്രതീക്ഷയിൽ ഞങ്ങൾ ലോക്ക് റിലീസ് ചെയ്യുകയും ഉറങ്ങുകയും ചെയ്യുന്നു. ഉണർന്ന്, ഞങ്ങൾ തുടക്കത്തിലേക്ക് മടങ്ങുകയും ലോക്ക് വീണ്ടും തൂക്കിയിടുകയും ഒരു പുതിയ റെക്കോർഡിംഗ് സൈക്കിൾ ആരംഭിക്കുകയും ചെയ്യുന്നു.

പൈപ്പ്ലൈനിൽ മതിയായ ഇടമുണ്ടെങ്കിൽ, ഞങ്ങൾ അതിലേക്ക് ഡാറ്റ എഴുതുന്നു എഴുതുക(). പരാമീറ്റർ i_size1 inode (പൈപ്പ്ലൈൻ ശൂന്യമാണെങ്കിൽ, അത് 0 ന് തുല്യമാകാം) അതിൽ ഇതിനകം അടങ്ങിയിരിക്കുന്ന ഡാറ്റയുടെ അവസാനം സൂചിപ്പിക്കുന്നു. മതിയായ റെക്കോർഡിംഗ് സ്പേസ് ഉണ്ടെങ്കിൽ, നമുക്ക് പൈപ്പ്ലൈൻ പൂരിപ്പിക്കാം i_size1 ഇതിനായി PIPESIZ. തുടർന്ന് ഞങ്ങൾ ലോക്ക് വിടുകയും പൈപ്പ്ലൈനിൽ നിന്ന് വായിക്കാൻ കാത്തിരിക്കുന്ന ഏത് പ്രക്രിയയും ഉണർത്താൻ ശ്രമിക്കുകയും ചെയ്യുന്നു. നമുക്ക് ആവശ്യമുള്ളത്ര ബൈറ്റുകൾ എഴുതാൻ കഴിഞ്ഞോ എന്നറിയാൻ ഞങ്ങൾ തുടക്കത്തിലേക്ക് മടങ്ങുന്നു. ഇത് പരാജയപ്പെടുകയാണെങ്കിൽ, ഞങ്ങൾ ഒരു പുതിയ റെക്കോർഡിംഗ് സൈക്കിൾ ആരംഭിക്കുന്നു.

സാധാരണയായി പരാമീറ്റർ i_mode അനുമതികൾ സംഭരിക്കുന്നതിന് inode ഉപയോഗിക്കുന്നു r, w и x. എന്നാൽ പൈപ്പ് ലൈനുകളുടെ കാര്യത്തിൽ, ചില പ്രക്രിയകൾ ബിറ്റുകൾ ഉപയോഗിച്ച് എഴുതുന്നതിനോ വായിക്കുന്നതിനോ കാത്തിരിക്കുന്നതായി ഞങ്ങൾ സൂചന നൽകുന്നു IREAD и IWRITE യഥാക്രമം. പ്രക്രിയ ഫ്ലാഗും കോളുകളും സജ്ജമാക്കുന്നു sleep(), കൂടാതെ ഭാവിയിൽ മറ്റേതെങ്കിലും പ്രക്രിയയ്ക്ക് കാരണമാകുമെന്ന് പ്രതീക്ഷിക്കുന്നു wakeup().

യഥാർത്ഥ മാന്ത്രികത സംഭവിക്കുന്നത് sleep() и wakeup(). അവയിൽ നടപ്പിലാക്കുന്നു slp.c, "നിങ്ങൾ ഇത് മനസ്സിലാക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നില്ല" എന്ന പ്രസിദ്ധമായ അഭിപ്രായത്തിൻ്റെ ഉറവിടം. ഭാഗ്യവശാൽ, ഞങ്ങൾ കോഡ് മനസ്സിലാക്കേണ്ടതില്ല, ചില അഭിപ്രായങ്ങൾ നോക്കുക:

/*
 * Give up the processor till a wakeup occurs
 * on chan, at which time the process
 * enters the scheduling queue at priority pri.
 * The most important effect of pri is that when
 * pri<0 a signal cannot disturb the sleep;
 * if pri>=0 signals will be processed.
 * Callers of this routine must be prepared for
 * premature return, and check that the reason for
 * sleeping has gone away.
 */
sleep(chan, pri) /* … */

/*
 * Wake up all processes sleeping on chan.
 */
wakeup(chan) /* … */

കാരണമാകുന്ന പ്രക്രിയ sleep() ഒരു പ്രത്യേക ചാനലിനായി, പിന്നീട് മറ്റൊരു പ്രക്രിയയാൽ ഉണർന്നേക്കാം, അത് കാരണമാകും wakeup() അതേ ചാനലിനായി. writep() и readp() അത്തരം ജോടിയാക്കിയ കോളുകളിലൂടെ അവരുടെ പ്രവർത്തനങ്ങൾ ഏകോപിപ്പിക്കുക. അതല്ല pipe.c എപ്പോഴും മുൻഗണന നൽകുന്നു PPIPE വിളിച്ചപ്പോൾ sleep(), അത്രമാത്രം sleep() ഒരു സിഗ്നൽ വഴി തടസ്സപ്പെട്ടേക്കാം.

ഇപ്പോൾ നമുക്ക് പ്രവർത്തനം മനസ്സിലാക്കാൻ എല്ലാം ഉണ്ട് readp():

readp(fp)
int *fp;
{
    register *rp, *ip;

    rp = fp;
    ip = rp->f_inode;

loop:
    /* Very conservative locking. */

    plock(ip);

    /*
     * If the head (read) has caught up with
     * the tail (write), reset both to 0.
     */

    if(rp->f_offset[1] == ip->i_size1) {
        if(rp->f_offset[1] != 0) {
            rp->f_offset[1] = 0;
            ip->i_size1 = 0;
            if(ip->i_mode&IWRITE) {
                ip->i_mode =& ~IWRITE;
                wakeup(ip+1);
            }
        }

        /*
         * If there are not both reader and
         * writer active, return without
         * satisfying read.
         */

        prele(ip);
        if(ip->i_count < 2)
            return;
        ip->i_mode =| IREAD;
        sleep(ip+2, PPIPE);
        goto loop;
    }

    /* Read and return */

    u.u_offset[0] = 0;
    u.u_offset[1] = rp->f_offset[1];
    readi(ip);
    rp->f_offset[1] = u.u_offset[1];
    prele(ip);
}

ഈ ഫംഗ്‌ഷൻ താഴെ നിന്ന് മുകളിലേക്ക് വായിക്കുന്നത് നിങ്ങൾക്ക് എളുപ്പമാണെന്ന് തോന്നിയേക്കാം. പൈപ്പ് ലൈനിൽ കുറച്ച് ഡാറ്റ ഉള്ളപ്പോൾ സാധാരണയായി "റീഡ് ആൻഡ് റിട്ടേൺ" ബ്രാഞ്ച് ഉപയോഗിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഞങ്ങൾ ഉപയോഗിക്കുന്നു റെഡി() നിലവിലുള്ളതിൽ നിന്ന് ആരംഭിച്ച് ലഭ്യമായ അത്രയും ഡാറ്റ ഞങ്ങൾ വായിക്കുന്നു f_offset വായിക്കുക, തുടർന്ന് അനുബന്ധ ഓഫ്സെറ്റിൻ്റെ മൂല്യം അപ്ഡേറ്റ് ചെയ്യുക.

തുടർന്നുള്ള റീഡുകളിൽ, റീഡ് ഓഫ്‌സെറ്റ് എത്തിയാൽ പൈപ്പ് ലൈൻ ശൂന്യമാകും i_size1 ഐനോഡിൽ. ഞങ്ങൾ സ്ഥാനം 0 ലേക്ക് പുനഃസജ്ജമാക്കുകയും പൈപ്പ്ലൈനിലേക്ക് എഴുതാൻ ആഗ്രഹിക്കുന്ന ഏത് പ്രക്രിയയും ഉണർത്താൻ ശ്രമിക്കുകയും ചെയ്യുന്നു. കൺവെയർ നിറയുമ്പോൾ നമുക്കറിയാം, writep() ഉറങ്ങിപ്പോകും ip+1. ഇപ്പോൾ പൈപ്പ് ലൈൻ ശൂന്യമായതിനാൽ, അതിൻ്റെ എഴുത്ത് ചക്രം പുനരാരംഭിക്കാൻ നമുക്ക് അതിനെ ഉണർത്താം.

വായിക്കാൻ ഒന്നുമില്ലെങ്കിൽ പിന്നെ readp() ഒരു പതാക സ്ഥാപിക്കാൻ കഴിയും IREAD ഉറങ്ങുകയും ചെയ്യും ip+2. എന്താണ് അവനെ ഉണർത്തുന്നതെന്ന് നമുക്കറിയാം writep(), അത് പൈപ്പ്ലൈനിലേക്ക് കുറച്ച് ഡാറ്റ എഴുതുമ്പോൾ.

എന്നതിലേക്കുള്ള അഭിപ്രായങ്ങൾ readi() and writei() " എന്നതിലൂടെ പാരാമീറ്ററുകൾ കൈമാറുന്നതിനുപകരം അത് മനസ്സിലാക്കാൻ നിങ്ങളെ സഹായിക്കുംu"ഒരു ഫയൽ, ഒരു സ്ഥാനം, മെമ്മറിയിൽ ഒരു ബഫർ എന്നിവ എടുക്കുകയും വായിക്കുന്നതിനോ എഴുതുന്നതിനോ ഉള്ള ബൈറ്റുകളുടെ എണ്ണം കണക്കാക്കുന്ന സാധാരണ I/O ഫംഗ്‌ഷനുകൾ പോലെ നമുക്ക് അവയെ കൈകാര്യം ചെയ്യാൻ കഴിയും.

/*
 * Read the file corresponding to
 * the inode pointed at by the argument.
 * The actual read arguments are found
 * in the variables:
 *    u_base        core address for destination
 *    u_offset    byte offset in file
 *    u_count        number of bytes to read
 *    u_segflg    read to kernel/user
 */
readi(aip)
struct inode *aip;
/* … */

/*
 * Write the file corresponding to
 * the inode pointed at by the argument.
 * The actual write arguments are found
 * in the variables:
 *    u_base        core address for source
 *    u_offset    byte offset in file
 *    u_count        number of bytes to write
 *    u_segflg    write to kernel/user
 */
writei(aip)
struct inode *aip;
/* … */

"യാഥാസ്ഥിതിക" തടയൽ പോലെ, പിന്നെ readp() и writep() അവരുടെ ജോലി പൂർത്തിയാകുന്നതുവരെ അല്ലെങ്കിൽ ഒരു ഫലം ലഭിക്കുന്നതുവരെ ഐനോഡ് തടയുക (അതായത്, വിളിക്കുക wakeup). plock() и prele() ലളിതമായി പ്രവർത്തിക്കുക: വ്യത്യസ്ത കോളുകൾ ഉപയോഗിച്ച് sleep и wakeup ഞങ്ങൾ ഇപ്പോൾ റിലീസ് ചെയ്ത ലോക്ക് ആവശ്യമുള്ള ഏത് പ്രക്രിയയും ഉണർത്താൻ ഞങ്ങളെ അനുവദിക്കുക:

/*
 * Lock a pipe.
 * If its already locked, set the WANT bit and sleep.
 */
plock(ip)
int *ip;
{
    register *rp;

    rp = ip;
    while(rp->i_flag&ILOCK) {
        rp->i_flag =| IWANT;
        sleep(rp, PPIPE);
    }
    rp->i_flag =| ILOCK;
}

/*
 * Unlock a pipe.
 * If WANT bit is on, wakeup.
 * This routine is also used to unlock inodes in general.
 */
prele(ip)
int *ip;
{
    register *rp;

    rp = ip;
    rp->i_flag =& ~ILOCK;
    if(rp->i_flag&IWANT) {
        rp->i_flag =& ~IWANT;
        wakeup(rp);
    }
}

എന്തുകൊണ്ടെന്ന് ആദ്യം എനിക്ക് മനസ്സിലായില്ല readp() കാരണമാകുന്നില്ല prele(ip) കോളിന് മുമ്പ് wakeup(ip+1). ഒന്നാമത്തെ കാര്യം writep() അതിൻ്റെ ചക്രത്തിൽ കാരണമാകുന്നു, ഇത് plock(ip), എങ്കിൽ അത് സ്തംഭനാവസ്ഥയിലേക്ക് നയിക്കുന്നു readp() എൻ്റെ ബ്ലോക്ക് ഇതുവരെ നീക്കം ചെയ്തിട്ടില്ല, അതിനാൽ എങ്ങനെയെങ്കിലും കോഡ് ശരിയായി പ്രവർത്തിക്കണം. നിങ്ങൾ നോക്കിയാൽ wakeup(), പിന്നീട് അത് സ്ലീപ്പിംഗ് പ്രക്രിയയെ എക്സിക്യൂട്ട് ചെയ്യാൻ തയ്യാറാണെന്ന് മാത്രം അടയാളപ്പെടുത്തുന്നു, അങ്ങനെ ഭാവിയിൽ sched() ശരിക്കും ലോഞ്ച് ചെയ്തു. അങ്ങനെ readp() കാരണമാകുന്നു wakeup(), ലോക്ക് നീക്കം ചെയ്യുന്നു, സജ്ജമാക്കുന്നു IREAD കോളുകളും sleep(ip+2)- ഇതെല്ലാം മുമ്പ് writep() സൈക്കിൾ പുനരാരംഭിക്കുന്നു.

ഇത് ആറാം പതിപ്പിലെ കൺവെയറുകളുടെ വിവരണം പൂർത്തിയാക്കുന്നു. ലളിതമായ കോഡ്, ദൂരവ്യാപകമായ അനന്തരഫലങ്ങൾ.

യുണിക്സിൻ്റെ ഏഴാം പതിപ്പ് (ജനുവരി 1979) നിരവധി പുതിയ ആപ്ലിക്കേഷനുകളും കേർണൽ സവിശേഷതകളും അവതരിപ്പിച്ച ഒരു പുതിയ പ്രധാന പതിപ്പായിരുന്നു (നാലു വർഷത്തിന് ശേഷം). ടൈപ്പ് കാസ്റ്റിംഗ്, യൂണിയനുകൾ, ഘടനകളിലേക്കുള്ള ടൈപ്പ് ചെയ്ത പോയിൻ്ററുകൾ എന്നിവയുടെ ഉപയോഗവുമായി ബന്ധപ്പെട്ട് ഇത് കാര്യമായ മാറ്റങ്ങൾക്ക് വിധേയമായി. എന്നിരുന്നാലും കൺവെയർ കോഡ് പ്രായോഗികമായി മാറ്റമില്ല. നമുക്ക് ഈ പതിപ്പ് ഒഴിവാക്കാം.

Xv6, യുണിക്സ് പോലെയുള്ള ഒരു ലളിതമായ കേർണൽ

കേർണൽ സൃഷ്ടിക്കാൻ Xv6 യുണിക്സിൻ്റെ ആറാം പതിപ്പ് സ്വാധീനിച്ചു, പക്ഷേ x86 പ്രൊസസറുകളിൽ പ്രവർത്തിക്കാൻ ആധുനിക സിയിൽ എഴുതിയിരിക്കുന്നു. കോഡ് വായിക്കാൻ എളുപ്പവും മനസ്സിലാക്കാവുന്നതുമാണ്. കൂടാതെ, TUHS ഉള്ള Unix ഉറവിടങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, നിങ്ങൾക്ക് ഇത് കംപൈൽ ചെയ്യാനും പരിഷ്‌ക്കരിക്കാനും PDP 11/70 അല്ലാതെ മറ്റൊന്നിൽ പ്രവർത്തിപ്പിക്കാനും കഴിയും. അതിനാൽ, ഈ കേർണൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലെ വിദ്യാഭ്യാസ സാമഗ്രിയായി സർവകലാശാലകളിൽ വ്യാപകമായി ഉപയോഗിക്കുന്നു. ഉറവിടങ്ങൾ Github-ൽ ഉണ്ട്.

കോഡിൽ വ്യക്തവും ചിന്തനീയവുമായ നടപ്പാക്കൽ അടങ്ങിയിരിക്കുന്നു പൈപ്പ്.സി, ഡിസ്കിൽ ഒരു ഐനോഡിന് പകരം മെമ്മറിയിൽ ഒരു ബഫർ പിന്തുണയ്ക്കുന്നു. ഇവിടെ ഞാൻ "ഘടനാപരമായ പൈപ്പ്ലൈൻ" എന്നതിൻ്റെയും പ്രവർത്തനത്തിൻ്റെയും നിർവചനം മാത്രമാണ് നൽകുന്നത് pipealloc():

#define PIPESIZE 512

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

int
pipealloc(struct file **f0, struct file **f1)
{
  struct pipe *p;

  p = 0;
  *f0 = *f1 = 0;
  if((*f0 = filealloc()) == 0 || (*f1 = filealloc()) == 0)
    goto bad;
  if((p = (struct pipe*)kalloc()) == 0)
    goto bad;
  p->readopen = 1;
  p->writeopen = 1;
  p->nwrite = 0;
  p->nread = 0;
  initlock(&p->lock, "pipe");
  (*f0)->type = FD_PIPE;
  (*f0)->readable = 1;
  (*f0)->writable = 0;
  (*f0)->pipe = p;
  (*f1)->type = FD_PIPE;
  (*f1)->readable = 0;
  (*f1)->writable = 1;
  (*f1)->pipe = p;
  return 0;

 bad:
  if(p)
    kfree((char*)p);
  if(*f0)
    fileclose(*f0);
  if(*f1)
    fileclose(*f1);
  return -1;
}

pipealloc() ഫംഗ്‌ഷനുകൾ ഉൾപ്പെടുന്ന ബാക്കി നടപ്പാക്കലിൻ്റെ അവസ്ഥ സജ്ജമാക്കുന്നു piperead(), pipewrite() и pipeclose(). യഥാർത്ഥ സിസ്റ്റം കോൾ sys_pipe ഒരു റാപ്പർ ആണ് നടപ്പിലാക്കിയത് sysfile.c. അദ്ദേഹത്തിൻ്റെ മുഴുവൻ കോഡും വായിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു. സങ്കീർണ്ണത ആറാം പതിപ്പിൻ്റെ സോഴ്സ് കോഡിൻ്റെ തലത്തിലാണ്, എന്നാൽ ഇത് വായിക്കാൻ വളരെ എളുപ്പവും കൂടുതൽ ആസ്വാദ്യകരവുമാണ്.

ലിനക്സ് 0.01

Linux 0.01 സോഴ്സ് കോഡ് കണ്ടെത്താം. അദ്ദേഹത്തിൽ പൈപ്പ് ലൈനുകൾ നടപ്പിലാക്കുന്നത് പഠിക്കുന്നത് പ്രബോധനമായിരിക്കും fs/pipe.c. പൈപ്പ്‌ലൈനെ പ്രതിനിധീകരിക്കാൻ ഇത് ഒരു ഐനോഡ് ഉപയോഗിക്കുന്നു, എന്നാൽ പൈപ്പ്‌ലൈൻ തന്നെ ആധുനിക സിയിൽ എഴുതിയിരിക്കുന്നു. ആറാം പതിപ്പ് കോഡിലൂടെ നിങ്ങൾ പ്രവർത്തിച്ചിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഇവിടെ പ്രശ്‌നങ്ങളൊന്നുമില്ല. ഫംഗ്ഷൻ ഇങ്ങനെയാണ് കാണപ്പെടുന്നത് write_pipe():

int write_pipe(struct m_inode * inode, char * buf, int count)
{
    char * b=buf;

    wake_up(&inode->i_wait);
    if (inode->i_count != 2) { /* no readers */
        current->signal |= (1<<(SIGPIPE-1));
        return -1;
    }
    while (count-->0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<<(SIGPIPE-1));
                return b-buf;
            }
            sleep_on(&inode->i_wait);
        }
        ((char *)inode->i_size)[PIPE_HEAD(*inode)] =
            get_fs_byte(b++);
        INC_PIPE( PIPE_HEAD(*inode) );
        wake_up(&inode->i_wait);
    }
    wake_up(&inode->i_wait);
    return b-buf;
}

ഘടനാപരമായ നിർവചനങ്ങൾ പോലും നോക്കാതെ, ഒരു റൈറ്റ് ഓപ്പറേഷൻ ഫലമുണ്ടോ എന്ന് പരിശോധിക്കാൻ ഐനോഡ് റഫറൻസ് കൗണ്ട് എങ്ങനെ ഉപയോഗിക്കുന്നുവെന്ന് നിങ്ങൾക്ക് കണ്ടെത്താനാകും. SIGPIPE. ബൈറ്റ്-ബൈ-ബൈറ്റ് പ്രവർത്തിക്കുന്നതിനു പുറമേ, ഈ ഫംഗ്ഷൻ മുകളിൽ വിവരിച്ച ആശയങ്ങളുമായി താരതമ്യം ചെയ്യാൻ എളുപ്പമാണ്. യുക്തി പോലും sleep_on/wake_up അത്ര അന്യമായി കാണുന്നില്ല.

ആധുനിക ലിനക്സ് കേർണലുകൾ, FreeBSD, NetBSD, OpenBSD

ഞാൻ വേഗം ചില ആധുനിക കേർണലുകളിലൂടെ ഓടി. അവയ്‌ക്കൊന്നും ഇനി ഡിസ്‌ക് ഇംപ്ലിമെൻ്റേഷൻ ഇല്ല (അത്ഭുതപ്പെടാനില്ല). ലിനക്സിന് അതിൻ്റേതായ നടപ്പാക്കൽ ഉണ്ട്. മൂന്ന് ആധുനിക ബിഎസ്ഡി കേർണലുകളിൽ ജോൺ ഡൈസൺ എഴുതിയ കോഡ് അടിസ്ഥാനമാക്കിയുള്ള നിർവ്വഹണങ്ങൾ അടങ്ങിയിട്ടുണ്ടെങ്കിലും, വർഷങ്ങളായി അവ പരസ്പരം വളരെ വ്യത്യസ്തമായിത്തീർന്നു.

വായിക്കാൻ fs/pipe.c (ലിനക്സിൽ) അല്ലെങ്കിൽ sys/kern/sys_pipe.c (*BSD-ൽ), ഇതിന് യഥാർത്ഥ സമർപ്പണം ആവശ്യമാണ്. ഇന്നത്തെ കോഡ് വെക്റ്റർ, അസിൻക്രണസ് I/O പോലുള്ള സവിശേഷതകൾക്കുള്ള പ്രകടനത്തെയും പിന്തുണയെയും കുറിച്ചുള്ളതാണ്. മെമ്മറി അലോക്കേഷൻ, ലോക്കുകൾ, കേർണൽ കോൺഫിഗറേഷൻ എന്നിവയുടെ വിശദാംശങ്ങൾ വളരെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു. ഒരു ആമുഖ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം കോഴ്‌സിന് കോളേജുകൾക്ക് വേണ്ടത് ഇതല്ല.

എന്തായാലും, ചില പഴയ പാറ്റേണുകൾ (ജനറേറ്റിംഗ് പോലെ) കുഴിക്കാൻ എനിക്ക് താൽപ്പര്യമുണ്ടായിരുന്നു SIGPIPE തിരികെയും EPIPE അടച്ച പൈപ്പ്ലൈനിലേക്ക് എഴുതുമ്പോൾ) ഈ വ്യത്യസ്ത ആധുനിക കേർണലുകളിലെല്ലാം. യഥാർത്ഥ ജീവിതത്തിൽ ഞാൻ ഒരിക്കലും ഒരു PDP-11 കമ്പ്യൂട്ടർ കാണില്ല, പക്ഷേ ഞാൻ ജനിക്കുന്നതിന് വർഷങ്ങൾക്ക് മുമ്പ് എഴുതിയ കോഡിൽ നിന്ന് ഇനിയും ഒരുപാട് പഠിക്കാനുണ്ട്.

2011-ൽ ദിവി കപൂർ എഴുതിയ ഒരു ലേഖനം:പൈപ്പുകളുടെയും ഫിഫോകളുടെയും ലിനക്സ് കേർണൽ നടപ്പിലാക്കൽ"ലിനക്സിൽ പൈപ്പ് ലൈനുകൾ (ഇപ്പോഴും) എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിൻ്റെ ഒരു അവലോകനം നൽകുന്നു. എ Linux-ൽ സമീപകാല പ്രതിബദ്ധത ആശയവിനിമയത്തിൻ്റെ പൈപ്പ് ലൈൻ മാതൃക കാണിക്കുന്നു, അതിൻ്റെ കഴിവുകൾ താൽക്കാലിക ഫയലുകളേക്കാൾ കൂടുതലാണ്; ആറാം പതിപ്പായ യുണിക്സ് കേർണലിൻ്റെ "വളരെ യാഥാസ്ഥിതിക ലോക്കിംഗിൽ" നിന്ന് പൈപ്പ്ലൈനുകൾ എത്രത്തോളം വന്നിരിക്കുന്നുവെന്നും കാണിക്കുന്നു.

അവലംബം: www.habr.com