યુનિક્સમાં પાઇપલાઇન્સ કેવી રીતે લાગુ કરવામાં આવે છે

આ લેખ યુનિક્સ કર્નલમાં પાઇપલાઇન્સના અમલીકરણનું વર્ણન કરે છે. હું કંઈક અંશે નિરાશ હતો કે તાજેતરના લેખ "યુનિક્સમાં પાઇપલાઇન્સ કેવી રીતે કામ કરે છે?"બહાર આવ્યું છે નથી આંતરિક રચના વિશે. હું ઉત્સુક બન્યો અને જવાબ શોધવા માટે જૂના સ્ત્રોતોમાં ખોદ્યો.

આપણે શું વાત કરી રહ્યા છીએ?

પાઇપલાઇન્સ, "કદાચ યુનિક્સમાં સૌથી મહત્વની શોધ," એ નાના કાર્યક્રમોને એકસાથે જોડવાની અંતર્ગત યુનિક્સ ફિલસૂફીની વ્યાખ્યાયિત લાક્ષણિકતા છે, તેમજ આદેશ વાક્ય પર એક પરિચિત ચિહ્ન છે:

$ 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 સોર્સ કોડ સાથે, પરંતુ આભાર યુનિક્સ હેરિટેજ સોસાયટી પર તમે ઓનલાઈન સર્ચ કરી શકો છો સ્ત્રોત કોડ યુનિક્સની જૂની આવૃત્તિઓ પણ.

TUHS આર્કાઇવ્સમાં ભટકવું એ મ્યુઝિયમની મુલાકાત લેવા જેવું છે. આપણે આપણો સહિયારો ઈતિહાસ જોઈ શકીએ છીએ અને જૂની ટેપ અને પ્રિન્ટ્સમાંથી આ બધી સામગ્રી થોડી-થોડી-થોડી-થોડી-થોડી-થોડી-થોડી વારમાં પુનઃપ્રાપ્ત કરવાના ઘણા વર્ષોના પ્રયત્નો માટે મને આદર છે. અને હું તે ટુકડાઓ વિશે તીવ્રપણે વાકેફ છું જે હજી પણ ગુમ છે.

કન્વેયર્સના પ્રાચીન ઇતિહાસ વિશેની અમારી જિજ્ઞાસાને સંતોષ્યા પછી, અમે સરખામણી માટે આધુનિક કર્નલોને જોઈ શકીએ છીએ.

માર્ગ દ્વારા, pipe કોષ્ટકમાં સિસ્ટમ કોલ નંબર 42 છે sysent[]. સંયોગ?

પરંપરાગત યુનિક્સ કર્નલો (1970-1974)

મને કોઈ નિશાન મળ્યા નથી pipe(2) ન તો અંદર PDP-7 યુનિક્સ (જાન્યુઆરી 1970), કે માં યુનિક્સ ની પ્રથમ આવૃત્તિ (નવેમ્બર 1971), ન તો અપૂર્ણ સ્ત્રોત કોડમાં બીજી આવૃત્તિ (જૂન 1972).

TUHS જણાવે છે કે યુનિક્સ ની ત્રીજી આવૃત્તિ (ફેબ્રુઆરી 1973) કન્વેયર્સ સાથેનું પ્રથમ સંસ્કરણ બન્યું:

યુનિક્સ 1973જી આવૃત્તિ એ એસેમ્બલી ભાષામાં લખાયેલ કર્નલ સાથેનું છેલ્લું સંસ્કરણ હતું, પરંતુ પાઇપલાઇન્સ સાથેનું પ્રથમ સંસ્કરણ પણ હતું. XNUMX દરમિયાન, ત્રીજી આવૃત્તિને સુધારવા માટે કામ હાથ ધરવામાં આવ્યું હતું, કર્નલને C માં ફરીથી લખવામાં આવ્યું હતું, અને તેથી યુનિક્સની ચોથી આવૃત્તિ દેખાઈ હતી.

એક વાચકને એક દસ્તાવેજનું સ્કેન મળ્યું જેમાં ડગ મેકિલરોયે "બગીચાની નળી જેવા પ્રોગ્રામ્સને કનેક્ટ કરવાનો" વિચાર પ્રસ્તાવિત કર્યો.

બ્રાયન કર્નિઘનના પુસ્તકમાંયુનિક્સ: એક ઇતિહાસ અને સંસ્મરણો", કન્વેયર્સના ઉદભવના ઇતિહાસમાં, આ દસ્તાવેજનો પણ ઉલ્લેખ કરવામાં આવ્યો છે: "... તે 30 વર્ષથી બેલ લેબ્સમાં મારી ઓફિસમાં દિવાલ પર લટકાવવામાં આવ્યો હતો." અહીં McIlroy સાથે મુલાકાત, અને માંથી બીજી વાર્તા મેકઇલરોયનું કાર્ય, 2014 માં લખાયેલ:

જ્યારે યુનિક્સ બહાર આવ્યું, ત્યારે કોરોટીન પ્રત્યેના મારા આકર્ષણને કારણે મને OSના લેખક, કેન થોમ્પસનને પૂછવામાં આવ્યું કે પ્રક્રિયામાં લખાયેલ ડેટાને માત્ર ઉપકરણમાં જ નહીં, પણ બીજી પ્રક્રિયામાં આઉટપુટ કરવા માટે પણ પરવાનગી આપવા માટે. કેને નક્કી કર્યું કે તે શક્ય છે. જો કે, ઓછામાં ઓછા તરીકે, તે ઇચ્છે છે કે દરેક સિસ્ટમ કાર્ય નોંધપાત્ર ભૂમિકા ભજવે. શું પ્રક્રિયાઓ વચ્ચે સીધું લખવું એ મધ્યવર્તી ફાઇલ પર લખવા કરતાં ખરેખર મોટો ફાયદો છે? તે ત્યારે જ હતું જ્યારે મેં આકર્ષક નામ "પાઇપલાઇન" અને પ્રક્રિયાઓ વચ્ચેની ક્રિયાપ્રતિક્રિયા માટે વાક્યરચનાનું વર્ણન સાથે ચોક્કસ દરખાસ્ત કરી ત્યારે જ કેને અંતે કહ્યું: "હું તે કરીશ!"

અને કર્યું. એક ભયંકર સાંજે, કેને કર્નલ અને શેલ બદલ્યા, તેઓ ઇનપુટ (જે પાઇપલાઇનમાંથી આવી શકે છે) કેવી રીતે સ્વીકારે છે તે પ્રમાણિત કરવા માટે ઘણા પ્રમાણભૂત પ્રોગ્રામ્સ નક્કી કર્યા અને ફાઇલના નામ પણ બદલ્યા. બીજા દિવસે, એપ્લિકેશનમાં પાઇપલાઇન્સનો ખૂબ વ્યાપક ઉપયોગ થવા લાગ્યો. અઠવાડિયાના અંત સુધીમાં, સચિવો વર્ડ પ્રોસેસરમાંથી પ્રિન્ટર પર દસ્તાવેજો મોકલવા માટે તેનો ઉપયોગ કરતા હતા. થોડા સમય પછી, કેને ક્લીનર કન્વેન્શન્સ સાથે પાઇપલાઇનના ઉપયોગને લપેટવા માટે મૂળ API અને વાક્યરચનાનું સ્થાન લીધું, જે ત્યારથી ઉપયોગમાં લેવાય છે.

કમનસીબે, ત્રીજી આવૃત્તિ યુનિક્સ કર્નલ માટેનો સ્રોત કોડ ખોવાઈ ગયો છે. અને જો કે આપણી પાસે કર્નલ સોર્સ કોડ C માં લખાયેલો છે ચોથી આવૃત્તિ, નવેમ્બર 1973 માં બહાર પાડવામાં આવ્યું હતું, પરંતુ તે સત્તાવાર રિલીઝના ઘણા મહિના પહેલા બહાર આવ્યું હતું અને તેમાં પાઇપલાઇન અમલીકરણ શામેલ નથી. તે શરમજનક છે કે આ સુપ્રસિદ્ધ યુનિક્સ ફંક્શનનો સ્રોત કોડ ખોવાઈ ગયો છે, કદાચ કાયમ માટે.

અમારી પાસે ટેક્સ્ટ દસ્તાવેજીકરણ છે pipe(2) બંને પ્રકાશનોમાંથી, જેથી તમે દસ્તાવેજીકરણ શોધીને પ્રારંભ કરી શકો ત્રીજી આવૃત્તિ (ચોક્કસ શબ્દો માટે, "મેન્યુઅલી" રેખાંકિત, શાબ્દિક શબ્દમાળા ^H, ત્યારબાદ અન્ડરસ્કોર!). આ પ્રોટો-pipe(2) એસેમ્બલી ભાષામાં લખાયેલ છે અને માત્ર એક ફાઇલ વર્ણનકર્તા પરત કરે છે, પરંતુ પહેલેથી જ અપેક્ષિત મુખ્ય કાર્યક્ષમતા પ્રદાન કરે છે:

સિસ્ટમ કૉલ પાઇપ પાઇપલાઇન તરીકે ઓળખાતી ઇનપુટ/આઉટપુટ મિકેનિઝમ બનાવે છે. રીટર્ન થયેલ ફાઇલ ડિસ્ક્રીપ્ટરનો ઉપયોગ વાંચવા અને લખવાની કામગીરી માટે કરી શકાય છે. જ્યારે પાઇપલાઇન પર કંઇક લખવામાં આવે છે, ત્યારે 504 બાઇટ્સ સુધીનો ડેટા બફર થાય છે, ત્યારબાદ લેખન પ્રક્રિયા સસ્પેન્ડ કરવામાં આવે છે. પાઇપલાઇનમાંથી વાંચતી વખતે, બફર થયેલ ડેટા દૂર કરવામાં આવે છે.

પછીના વર્ષ સુધીમાં કર્નલને C માં ફરીથી લખવામાં આવ્યું હતું, અને પાઇપ(2) ચોથી આવૃત્તિમાં પ્રોટોટાઇપ સાથે તેનો આધુનિક દેખાવ પ્રાપ્ત કર્યો "pipe(fildes)"

સિસ્ટમ કૉલ પાઇપ પાઇપલાઇન તરીકે ઓળખાતી ઇનપુટ/આઉટપુટ મિકેનિઝમ બનાવે છે. રીટર્ન કરેલ ફાઇલ ડિસ્ક્રીપ્ટર્સનો ઉપયોગ વાંચવા અને લખવાની કામગીરીમાં કરી શકાય છે. જ્યારે પાઈપલાઈન પર કંઈક લખવામાં આવે છે, ત્યારે r1 (resp. fildes[1]) માં પરત કરવામાં આવેલ હેન્ડલનો ઉપયોગ કરવામાં આવે છે, ડેટાના 4096 બાઈટ્સ પર બફર કરવામાં આવે છે, ત્યારબાદ લખવાની પ્રક્રિયા સસ્પેન્ડ કરવામાં આવે છે. પાઇપલાઇનમાંથી વાંચતી વખતે, હેન્ડલ r0 પર પાછું આવે છે (resp. fildes[0]) ડેટા લે છે.

એવું માનવામાં આવે છે કે એકવાર પાઇપલાઇન વ્યાખ્યાયિત કરવામાં આવે છે, બે (અથવા વધુ) સંચાર પ્રક્રિયાઓ (અનુગામી કૉલ્સ દ્વારા બનાવવામાં આવે છે. કાંટો) કોલનો ઉપયોગ કરીને પાઇપલાઇનમાંથી ડેટા ટ્રાન્સફર કરશે વાંચવું и લખી.

શેલમાં પાઇપલાઇન દ્વારા જોડાયેલ પ્રક્રિયાઓની રેખીય શ્રેણીને વ્યાખ્યાયિત કરવા માટે એક વાક્યરચના છે.

ખાલી પાઈપલાઈનમાંથી વાંચવા માટેના કોલ્સ (જેમાં કોઈ બફર ડેટા નથી) જેનો માત્ર એક છેડો છે (તમામ લેખન ફાઇલ વર્ણનકર્તાઓ બંધ છે) "ફાઈલનો અંત" પરત કરે છે. સમાન પરિસ્થિતિમાં લખવા માટેના કૉલ્સને અવગણવામાં આવે છે.

સૌથી વહેલું સાચવેલ પાઇપલાઇન અમલીકરણ સંદર્ભ આપે છે યુનિક્સની પાંચમી આવૃત્તિ માટે (જૂન 1974), પરંતુ તે લગભગ સમાન છે જે આગામી પ્રકાશનમાં દેખાયા હતા. ટિપ્પણીઓ હમણાં જ ઉમેરવામાં આવી છે, જેથી તમે પાંચમી આવૃત્તિ છોડી શકો.

યુનિક્સની છઠ્ઠી આવૃત્તિ (1975)

ચાલો યુનિક્સ સોર્સ કોડ વાંચવાનું શરૂ કરીએ છઠ્ઠી આવૃત્તિ (મે 1975). મોટે ભાગે આભાર લાયન્સ અગાઉના સંસ્કરણોના સ્ત્રોતો કરતાં તે શોધવાનું ખૂબ સરળ છે:

ઘણા વર્ષોથી પુસ્તક લાયન્સ બેલ લેબ્સની બહાર ઉપલબ્ધ યુનિક્સ કર્નલ પરનો એકમાત્ર દસ્તાવેજ હતો. છઠ્ઠી આવૃત્તિના લાયસન્સે શિક્ષકોને તેના સ્રોત કોડનો ઉપયોગ કરવાની મંજૂરી આપી હોવા છતાં, સાતમી આવૃત્તિના લાયસન્સે આ શક્યતાને બાકાત રાખી હતી, તેથી પુસ્તક ગેરકાયદેસર ટાઈપ લખેલી નકલોના રૂપમાં વિતરિત કરવામાં આવ્યું હતું.

આજે તમે પુસ્તકનું રિપ્રિન્ટ ખરીદી શકો છો, જેનું કવર કોપી મશીન પર વિદ્યાર્થીઓને બતાવે છે. અને વોરેન ટૂમી (જેમણે TUHS પ્રોજેક્ટ શરૂ કર્યો)નો આભાર તમે ડાઉનલોડ કરી શકો છો છઠ્ઠી આવૃત્તિ માટે સ્ત્રોત કોડ સાથે પીડીએફ ફાઇલ. હું તમને એક ખ્યાલ આપવા માંગુ છું કે ફાઇલ બનાવવા માટે કેટલી મહેનત કરવામાં આવી છે:

15 કરતાં વધુ વર્ષ પહેલાં, મેં આપેલ સ્રોત કોડની એક નકલ ટાઈપ કરી હતી લાયન્સ, કારણ કે મને અજ્ઞાત સંખ્યામાં અન્ય નકલોમાંથી મારી નકલની ગુણવત્તા ગમતી નથી. TUHS હજુ સુધી અસ્તિત્વમાં નથી અને મારી પાસે જૂના સ્ત્રોતોની ઍક્સેસ નથી. પરંતુ 1988 માં, મને એક જૂની 9-ટ્રેક ટેપ મળી જેમાં PDP11 કમ્પ્યુટરમાંથી બેકઅપ હતું. તે કામ કરતું હતું કે કેમ તે કહેવું મુશ્કેલ હતું, પરંતુ એક અકબંધ /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 ફાઇલો માટે, તેઓ અનુરૂપ છે inode ધ્વજ 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;
}

ટિપ્પણી સ્પષ્ટપણે વર્ણવે છે કે અહીં શું થઈ રહ્યું છે. પરંતુ કોડને સમજવું એટલું સરળ નથી, આંશિક રીતે માર્ગને કારણે "સ્ટ્રક્ચર યુઝર યુ» અને રજીસ્ટર R0 и R1 સિસ્ટમ કૉલ પરિમાણો અને વળતર મૂલ્યો પસાર થાય છે.

ચાલો સાથે પ્રયાસ કરીએ ialloc() ડિસ્ક પર મૂકો inode (ઇન્ડેક્સ હેન્ડલ), અને મદદ સાથે falloc() - મેમરીમાં બે મૂકો ફાઇલ. જો બધું બરાબર રહેશે, તો અમે આ ફાઇલોને પાઇપલાઇનના બે છેડા તરીકે ઓળખવા માટે ફ્લેગ્સ સેટ કરીશું, તેમને સમાન ઇનોડ (જેની સંદર્ભ ગણતરી 2 પર સેટ કરવામાં આવશે) તરફ નિર્દેશિત કરીશું, અને આઇનોડને સંશોધિત અને ઉપયોગમાં છે તરીકે ચિહ્નિત કરીશું. ની વિનંતીઓ પર ધ્યાન આપો મે મુક્યુ() નવા આઇનોડમાં સંદર્ભ ગણતરી ઘટાડવા માટે ભૂલ પાથમાં.

pipe() મારફતે જ જોઈએ R0 и R1 વાંચવા અને લખવા માટે ફાઇલ વર્ણનકર્તા નંબરો પરત કરો. falloc() ફાઈલ સ્ટ્રક્ચરમાં પોઈન્ટર પરત કરે છે, પણ મારફતે "રીટર્ન" પણ કરે છે u.u_ar0[R0] અને ફાઇલ વર્ણનકર્તા. એટલે કે, કોડ સાચવે છે r વાંચવા માટે ફાઇલ વર્ણનકર્તા અને સીધા જ લખવા માટે ફાઇલ વર્ણનકર્તા સોંપે છે u.u_ar0[R0] બીજા કોલ પછી falloc().

ધ્વજ FPIPE, જે આપણે પાઇપલાઇન બનાવતી વખતે સેટ કરીએ છીએ, તે કાર્યના વર્તનને નિયંત્રિત કરે છે sys2.c માં rdwr()ચોક્કસ 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. પ્રથમ આપણે inode લોક કરવાની જરૂર છે (નીચે જુઓ plock/prele).

પછી અમે inode સંદર્ભ કાઉન્ટર તપાસીએ છીએ. જ્યાં સુધી પાઇપલાઇનના બંને છેડા ખુલ્લા રહે ત્યાં સુધી કાઉન્ટર 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 inode ખાતે. અમે સ્થિતિને 0 પર રીસેટ કરીએ છીએ અને પાઇપલાઇન પર લખવા માંગતી કોઈપણ પ્રક્રિયાને જાગૃત કરવાનો પ્રયાસ કરીએ છીએ. આપણે જાણીએ છીએ કે જ્યારે કન્વેયર ભરાઈ જાય છે, writep() પર સૂઈ જશે ip+1. અને હવે જ્યારે પાઈપલાઈન ખાલી છે, તો અમે તેનું લખવાનું ચક્ર ફરી શરૂ કરવા માટે તેને જાગૃત કરી શકીએ છીએ.

જો તમારી પાસે વાંચવા માટે કંઈ નથી, તો પછી readp() ધ્વજ સેટ કરી શકે છે IREAD અને સૂઈ જાઓ ip+2. અમે જાણીએ છીએ કે તેને શું જાગૃત કરશે writep(), જ્યારે તે પાઇપલાઇન પર અમુક ડેટા લખે છે.

પર ટિપ્પણીઓ readi() અને 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 પ્રોસેસરો પર ચલાવવા માટે આધુનિક C માં લખાયેલ છે. કોડ વાંચવામાં સરળ અને સમજી શકાય તેવું છે. ઉપરાંત, TUHS સાથે યુનિક્સ સ્ત્રોતોથી વિપરીત, તમે તેને કમ્પાઈલ કરી શકો છો, તેને સંશોધિત કરી શકો છો અને 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. આ પાઇપલાઇનનું પ્રતિનિધિત્વ કરવા માટે ઇનોડનો ઉપયોગ કરે છે, પરંતુ પાઇપલાઇન પોતે આધુનિક C માં લખાયેલ છે. જો તમે 6ઠ્ઠી આવૃત્તિ કોડ દ્વારા તમારી રીતે કામ કર્યું હોય, તો તમને અહીં કોઈ મુશ્કેલી નહીં પડે. આ ફંક્શન જેવો દેખાય છે 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 એટલો એલિયન નથી લાગતો.

આધુનિક લિનક્સ કર્નલ, ફ્રીબીએસડી, નેટબીએસડી, ઓપનબીએસડી

હું ઝડપથી કેટલાક આધુનિક કર્નલો મારફતે ચાલી હતી. તેમાંના કોઈપણ પાસે હવે ડિસ્ક અમલીકરણ નથી (આશ્ચર્યજનક નથી). લિનક્સનું પોતાનું અમલીકરણ છે. જો કે ત્રણ આધુનિક BSD કર્નલો જોન ડાયસન દ્વારા લખવામાં આવેલા કોડ પર આધારિત અમલીકરણો ધરાવે છે, વર્ષોથી તેઓ એકબીજાથી ખૂબ જ અલગ થઈ ગયા છે.

વાંચવા માટે fs/pipe.c (લિનક્સ પર) અથવા sys/kern/sys_pipe.c (*BSD પર), તે વાસ્તવિક સમર્પણ લે છે. આજનો કોડ વેક્ટર અને અસિંક્રોનસ I/O જેવી સુવિધાઓ માટે કામગીરી અને સમર્થન વિશે છે. અને મેમરી ફાળવણી, તાળાઓ અને કર્નલ રૂપરેખાંકનની વિગતો મોટા પ્રમાણમાં બદલાય છે. કોલેજોને પ્રારંભિક ઓપરેટિંગ સિસ્ટમ કોર્સ માટે આ જરૂરી નથી.

કોઈપણ રીતે, મને કેટલીક જૂની પેટર્ન ખોદવામાં રસ હતો (જેમ કે જનરેટ કરવું SIGPIPE અને પાછા ફરો EPIPE બંધ પાઇપલાઇન પર લખતી વખતે) આ તમામ વિવિધ આધુનિક કર્નલોમાં. હું કદાચ વાસ્તવિક જીવનમાં PDP-11 કોમ્પ્યુટર ક્યારેય નહીં જોઉં, પરંતુ મારા જન્મના વર્ષો પહેલા લખાયેલા કોડમાંથી હજુ ઘણું શીખવાનું બાકી છે.

2011 માં દિવી કપૂર દ્વારા લખાયેલ લેખ:પાઇપ્સ અને FIFOs નું Linux કર્નલ અમલીકરણ" Linux માં પાઇપલાઇન્સ (હજુ પણ) કેવી રીતે કાર્ય કરે છે તેની ઝાંખી આપે છે. એ Linux માં તાજેતરની પ્રતિબદ્ધતા ક્રિયાપ્રતિક્રિયાના પાઇપલાઇન મોડેલને સમજાવે છે, જેની ક્ષમતાઓ અસ્થાયી ફાઇલોની ક્ષમતા કરતાં વધી જાય છે; અને છઠ્ઠી આવૃત્તિ યુનિક્સ કર્નલની "ખૂબ જ રૂઢિચુસ્ત લોકીંગ" થી પાઇપલાઇન્સ કેટલી દૂર આવી છે તે પણ દર્શાવે છે.

સોર્સ: www.habr.com