Erlang 21

erlang




erlang

erlang

मॉड्यूल

erlang

मॉड्यूल सारांश

एर्लांग बीआईएफएस।

विवरण

कन्वेंशन द्वारा, अधिकांश बिल्ट-इन फ़ंक्शंस (BIFs) इस मॉड्यूल में शामिल किए गए हैं। कुछ बीआईएफ को एरलांग प्रोग्रामिंग भाषा के भाग के रूप में अधिक या कम देखा जाता है और ऑटो-आयातित होते हैं । इस प्रकार, मॉड्यूल नाम निर्दिष्ट करना आवश्यक नहीं है। उदाहरण के लिए, कॉल atom_to_list(erlang) और erlang:atom_to_list(erlang) समान हैं।

ऑटो-आयातित बीआईएफ को बिना मॉड्यूल उपसर्ग के सूचीबद्ध किया गया है। मॉड्यूल उपसर्ग के साथ सूचीबद्ध बीआईएफ ऑटो-आयातित नहीं हैं।

BIF विभिन्न कारणों से विफल हो सकते हैं। यदि गलत प्रकार के तर्कों के साथ बुलाया जाता है, तो सभी बीआईएफ badarg किसी कारण के badarg हो जाते हैं। प्रत्येक व्यक्तिगत BIF के विवरण में अन्य कारणों का वर्णन किया गया है।

कुछ बीआईएफ को गार्ड परीक्षणों में उपयोग किया जा सकता है और "गार्ड परीक्षण में अनुमति है" के साथ चिह्नित किया जाता है।

जानकारी का प्रकार

ext_binary() = binary()

एक बाइनरी डेटा ऑब्जेक्ट, एर्लांग बाहरी शब्द प्रारूप के अनुसार संरचित।

iovec() = [binary()]

बायनेरिज़ की एक सूची। यह डेटाटाइप enif_inspect_iovec साथ उपयोग करने के लिए उपयोगी है।

message_queue_data() = off_heap | on_heap
timestamp() =
{MegaSecs :: integer() >= 0,
Secs :: integer() >= 0,
MicroSecs :: integer() >= 0}

time_unit() =
integer() >= 1 |
second |
millisecond |
microsecond |
nanosecond |
native |
perf_counter |
deprecated_time_unit()

समर्थित समय इकाई प्रतिनिधित्व:

PartsPerSecond :: integer() >= 1

समय इकाई प्रति सेकंड भागों में व्यक्त की जाती है। यही है, टाइम यूनिट 1/PartsPerSecond सेकंड के बराबर है।

second

पूर्णांक 1 द्वारा प्रस्तुत समय इकाई का प्रतीकात्मक प्रतिनिधित्व।

millisecond

पूर्णांक 1000 द्वारा प्रस्तुत समय इकाई का प्रतीकात्मक प्रतिनिधित्व।

microsecond

पूर्णांक 1000000 द्वारा प्रस्तुत समय इकाई का प्रतीकात्मक प्रतिनिधित्व।

nanosecond

पूर्णांक 1000000000 द्वारा प्रतिनिधित्व टाइम यूनिट का प्रतीकात्मक प्रतिनिधित्व।

native

एर्लांग रनटाइम सिस्टम द्वारा उपयोग की जाने वाली देशी समय इकाई का प्रतीकात्मक प्रतिनिधित्व।

native समय इकाई रनटाइम सिस्टम प्रारंभ पर निर्धारित की जाती है, और रनटाइम सिस्टम समाप्त होने तक समान रहता है। यदि कोई रनटाइम सिस्टम बंद कर दिया जाता है और फिर से (उसी मशीन पर भी) शुरू होता है, तो नए रनटाइम सिस्टम उदाहरण की native समय इकाई पुराने रनटाइम सिस्टम के उदाहरण से अलग हो सकती है।

erlang:convert_time_unit(1, second, native) कॉल करके native समय इकाई का एक अनुमान प्राप्त कर सकते हैं। परिणाम प्रति सेकंड पूरे native समय इकाइयों की संख्या के बराबर होता native । यदि प्रति सेकंड native समय इकाइयों की संख्या पूरी संख्या में नहीं जुड़ती है, तो परिणाम नीचे की ओर होता है।

ध्यान दें

native समय इकाई का मूल्य आपको कम या ज्यादा देता है और समय मूल्यों की गुणवत्ता के बारे में कोई जानकारी नहीं देता है। यह resolution और समय मूल्यों की precision के लिए एक सीमा निर्धारित करता है, लेकिन यह समय के मूल्यों की accuracy के बारे में कोई जानकारी नहीं देता है। native समय इकाई का संकल्प और समय मानों का संकल्प काफी भिन्न हो सकता है।

perf_counter

एर्लांग रनटाइम सिस्टम द्वारा उपयोग किए जाने वाले प्रदर्शन काउंटर टाइम यूनिट का प्रतीकात्मक प्रतिनिधित्व।

perf_counter टाइम यूनिट native टाइम यूनिट की तरह ही व्यवहार करती native । यही है, यह रनटाइम पुनरारंभ के बीच भिन्न हो सकता है। इस प्रकार के मान प्राप्त करने के लिए, os:perf_counter/0 कॉल करें।

deprecated_time_unit()

पश्च-संगतता के लिए रखा गया प्रतीकात्मक प्रतीकात्मक प्रतिनिधित्व।

time_unit/0 प्रकार बढ़ाया जा सकता है। समय इकाइयों के बीच समय मानों को परिवर्तित करने के लिए, erlang:convert_time_unit/3 उपयोग करें erlang:convert_time_unit/3

deprecated_time_unit() =
seconds | milli_seconds | micro_seconds | nano_seconds

time_unit() प्रकार भी निम्न पदावनत प्रतीकात्मक समय इकाइयों से मिलकर बनता है:

seconds

time_unit() समान।

milli_seconds

time_unit() समान।

micro_seconds

time_unit() रूप में भी।

nano_seconds

time_unit() समान।

dist_handle()

वितरण चैनल की पहचान करने वाला एक अपारदर्शी हैंडल।

निर्यात

एब्स (फ्लोट) -> फ्लोट ()
abs (इंट) -> पूर्णांक ()> = 0

प्रकार

एक पूर्णांक या फ्लोट लौटाता है जो Float या Int का अंकगणितीय निरपेक्ष मान है, उदाहरण के लिए:

> abs(-3.33).
3.33
> abs(-3).
3

गार्ड परीक्षण में अनुमति है।

erlang: adler32 (डेटा) -> पूर्णांक ()> = 0

प्रकार

गणना करता है और Data लिए adler32 चेकसम लौटाता है।

erlang: adler32 (OldAdler, Data) -> पूर्णांक ()> = 0

प्रकार

पिछले चेकसम, OldAdler को Data के चेकसम के साथ जोड़कर adler32 चेकसम की गणना जारी रखता है।

निम्नलिखित कोड:

X = erlang:adler32(Data1),
Y = erlang:adler32(X,Data2).

इस के रूप में Y को एक ही मूल्य प्रदान करता है:

Y = erlang:adler32([Data1,Data2]).
erlang: adler32_combine (FirstAdler, SecondAdler, SecondSize) ->
पूर्णांक ()> = 0

प्रकार

दो पहले से गणना की गई adler32 चेकसम को मिलाता है। इस अभिकलन को दूसरे चेकसम के लिए ज्ञात ऑब्जेक्ट ऑब्जेक्ट के आकार की आवश्यकता होती है।

निम्नलिखित कोड:

Y = erlang:adler32(Data1),
Z = erlang:adler32(Y,Data2).

Z को समान मान प्रदान करता है:

X = erlang:adler32(Data1),
Y = erlang:adler32(Data2),
Z = erlang:adler32_combine(X,Y,iolist_size(Data2)).
erlang: append_element (Tuple1, टर्म) -> Tuple2

प्रकार

एक नया tuple देता है जिसमें Tuple1 तुलना में एक तत्व अधिक होता है, और Tuple1 में तत्व शामिल होते हैं और अंतिम तत्व के रूप में Term होता है। सूची के समान शब्दार्थ_तो_टुपल list_to_tuple(tuple_to_list(Tuple1) ++ [Term]) , लेकिन बहुत तेज़। उदाहरण:

> erlang:append_element({one, two}, three).
{one,two,three}
लागू करें (मज़ा, आर्ग्स) -> शब्द ()

प्रकार

तर्क के रूप में Args में तत्वों को पारित करते हुए, एक मजेदार कॉल।

यदि तर्कों में तत्वों की संख्या को संकलित समय पर जाना जाता है, तो कॉल को Fun(Arg1, Arg2, ... ArgN) रूप में बेहतर लिखा जाता है।

चेतावनी

इससे पहले, Fun को {Module, Function} रूप में भी निर्दिष्ट किया जा सकता है {Module, Function} apply(Module, Function, Args) करने के apply(Module, Function, Args) समान apply(Module, Function, Args) यह उपयोग पदावनत है और भविष्य के रिलीज में काम करना बंद कर देगा।

लागू करें (मॉड्यूल, फ़ंक्शन, आर्ग) -> शब्द ()

प्रकार

Module में Args में Function लागू करने का परिणाम देता है। लागू फ़ंक्शन को Module से निर्यात किया जाना चाहिए। फंक्शन की Args की लंबाई है। उदाहरण:

> apply(lists, reverse, [[a, b, c]]).
[c,b,a]
> apply(erlang, atom_to_list, ['Erlang']).
"Erlang"

यदि तर्कों की संख्या को संकलन समय पर जाना जाता है, तो कॉल को Module:Function(Arg1, Arg2, ..., ArgN) रूप में बेहतर लिखा जाता है।

विफलता: error_handler:undefined_function/3 को कहा जाता है यदि लागू फ़ंक्शन निर्यात नहीं किया जाता है। त्रुटि हैंडलर को फिर से परिभाषित किया जा सकता है (देखें process_flag/2 )। यदि error_handler अपरिभाषित है, या यदि उपयोगकर्ता ने डिफ़ॉल्ट error_handler को फिर से परिभाषित किया है, तो प्रतिस्थापन मॉड्यूल अपरिभाषित है, कारण error_handler साथ एक त्रुटि उत्पन्न होती है।

atom_to_binary (एटम, एन्कोडिंग) -> बाइनरी ()

प्रकार

Atom के पाठ प्रतिनिधित्व के लिए एक द्विआधारी देता है। यदि Encoding latin1 , पाठ प्रतिनिधित्व में प्रत्येक चरित्र के लिए एक बाइट मौजूद है। यदि Encoding utf8 या unicode , तो वर्ण UTF-8 का उपयोग करके एन्कोडेड हैं जहां वर्णों को एकाधिक बाइट्स की आवश्यकता हो सकती है।

ध्यान दें

Erlang / OTP 20 के अनुसार, परमाणुओं में कोई भी यूनिकोड वर्ण हो सकता है और atom_to_binary(Atom, latin1) Atom लिए पाठ प्रतिनिधित्व में यूनिकोड वर्ण> 255 होने पर विफल हो सकता है।

उदाहरण:

> atom_to_binary('Erlang', latin1).
<<"Erlang">>
atom_to_list (एटम) -> स्ट्रिंग ()

प्रकार

उदाहरण के लिए, Atom के पाठ प्रतिनिधित्व के अनुरूप एक स्ट्रिंग लौटाता है:

> atom_to_list('Erlang').
"Erlang"
बाइनरी_पार्ट (विषय, स्थिति) -> बाइनरी ()

प्रकार

PosLen द्वारा वर्णित बाइनरी का हिस्सा PosLen

एक बाइनरी के अंत में बाइट्स निकालने के लिए नकारात्मक लंबाई का उपयोग किया जा सकता है, उदाहरण के लिए:

1> Bin = <<1,2,3,4,5,6,7,8,9,10>>.
2> binary_part(Bin,{byte_size(Bin), -5}).
<<6,7,8,9,10>>

विफलता: badarg अगर बाइनरी के बाहर किसी भी तरह से संदर्भ देता है।

Start शून्य-आधारित है, जो है:

1> Bin = <<1,2,3>>
2> binary_part(Bin,{0,2}).
<<1,2>>

PosLen शब्दार्थ के बारे में जानकारी के लिए, binary(3)

गार्ड परीक्षण में अनुमति है।

बाइनरी_पार्ट (विषय, प्रारंभ, लंबाई) -> बाइनरी ()

प्रकार

binary_part(Subject, {Start, Length})

गार्ड परीक्षण में अनुमति है।

Binary_to_atom (बाइनरी, एन्कोडिंग) -> परमाणु ()

प्रकार

वह परमाणु लौटाता है जिसका पाठ प्रतिनिधित्व Binary । यदि Encoding लैटिन 1 है, तो बाइनरी में बाइट्स का कोई अनुवाद नहीं किया जाता है। यदि Encoding utf8 या unicode , तो बाइनरी में वैध UTF-8 क्रम होना चाहिए।

ध्यान दें

binary_to_atom(Binary, utf8) / ओटीपी 20 से, binary_to_atom(Binary, utf8) , binary_to_atom(Binary, utf8) 8 binary_to_atom(Binary, utf8) किसी भी यूनिकोड चरित्र को एन्कोड करने में सक्षम है। पूर्ववर्ती संस्करण विफल होंगे यदि बाइनरी में यूनिकोड वर्ण> 255 हों। परमाणुओं में यूनिकोड समर्थन के बारे में अधिक जानकारी के लिए, उपयोगकर्ता के गाइड में "बाहरी शब्द प्रारूप" खंड में note on UTF-8 encoded atoms देखें।

उदाहरण:

> binary_to_atom(<<"Erlang">>, latin1).
'Erlang'
> binary_to_atom(<<1024/utf8>>, utf8).
'Ѐ'
Binary_to_existing_atom (बाइनरी, एन्कोडिंग) -> परमाणु ()

प्रकार

binary_to_atom/2 , लेकिन परमाणु मौजूद होना चाहिए।

असफलता: अगर परमाणु मौजूद नहीं है, तो badarg

ध्यान दें

ध्यान दें कि संकलक दूर परमाणुओं का अनुकूलन कर सकता है। उदाहरण के लिए, कंपाइलर atom_to_list(some_atom) को "some_atom" फिर से atom_to_list(some_atom) । यदि उस अभिव्यक्ति का केवल उल्लेख किया गया है जिसमें मॉड्यूल में some_atom है, तो परमाणु लोड नहीं किया जाएगा जब मॉड्यूल लोड किया जाता है, और binary_to_existing_atom(<<"some_atom">>, utf8) बाद की कॉल विफल हो जाएगी।

बाइनरी_टो_फ्लोट (बाइनरी) -> फ्लोट ()

प्रकार

उदाहरण के लिए, जिसका पाठ प्रतिनिधित्व Binary है फ्लोट लौटाता है:

> binary_to_float(<<"2.2017764e+0">>).
2.2017764

विफलता: badarg अगर Binary में फ्लोट का खराब प्रतिनिधित्व होता है।

बाइनरी_टो_इन्टेगर (बाइनरी) -> पूर्णांक ()

प्रकार

एक पूर्णांक देता है जिसका पाठ प्रतिनिधित्व Binary , उदाहरण के लिए:

> binary_to_integer(<<"123">>).
123

विफलता: badarg अगर Binary में पूर्णांक का एक बुरा प्रतिनिधित्व होता है।

बाइनरी_टो_इन्टेगर (बाइनरी, बेस) -> पूर्णांक ()

प्रकार

एक पूर्णांक देता है जिसका आधार में पाठ प्रतिनिधित्व Binary , उदाहरण के लिए:

> binary_to_integer(<<"3FF">>, 16).
1023

विफलता: badarg अगर Binary में पूर्णांक का एक बुरा प्रतिनिधित्व होता है।

बाइनरी_टो_लिस्ट (बाइनरी) -> [बाइट ()]

प्रकार

Binary के बाइट्स के अनुरूप पूर्णांक की एक सूची देता है।

बाइनरी_टो_लिस्ट (बाइनरी, स्टार्ट, स्टॉप) -> [बाइट ()]

प्रकार

1.बाइट_साइज़ ( Binary )

binary_to_list/1 , लेकिन बाइट्स से संबंधित पूर्णांकों की सूची को स्थिति से लौटाता है। Start से स्थिति Binary में Stop । बाइनरी में स्थिति 1 से शुरू होती है।

ध्यान दें

इस फ़ंक्शन द्वारा उपयोग किए जाने वाले बायनेरिज़ के लिए एक-आधारित अनुक्रमण को पदावनत किया जाता है। नया कोड binary:bin_to_list/3 का उपयोग करना है binary:bin_to_list/3 इसके बजाय STDLIB में bin_to_list binary:bin_to_list/3 । मॉड्यूल binary में सभी फ़ंक्शन लगातार शून्य-आधारित अनुक्रमण का उपयोग करते हैं।

बाइनरी_टो_टरम (बाइनरी) -> शब्द ()

प्रकार

एक एर्लैंग शब्द लौटाता है जो द्विआधारी वस्तु Binary को डिकोड करने का परिणाम है, जिसे Erlang external term format अनुसार एन्कोड किया जाना चाहिए।

> Bin = term_to_binary(hello).
<<131,100,0,5,104,101,108,108,111>>
> hello = binary_to_term(Bin).
hello
चेतावनी

जब अविश्वासी स्रोतों से बायनेरिज़ को डिकोड किया जाता है, तो डेनियल ऑफ़ सर्विस हमलों को रोकने के लिए binary_to_term/2 का उपयोग करने पर विचार करें।

term_to_binary/1 और binary_to_term/2 भी देखें।

Binary_to_term (बाइनरी, ऑप्स) -> शब्द () | {शब्द (), प्रयुक्त}

प्रकार

binary_to_term/1 , लेकिन ये विकल्प लेते हैं:

safe

एक अविश्वसनीय स्रोत से बायनेरिज़ प्राप्त करते समय इस विकल्प का उपयोग करें।

सक्षम होने पर, यह डेटा को डीकोड करने से रोकता है जिसका उपयोग एर्लांग सिस्टम पर हमला करने के लिए किया जा सकता है। असुरक्षित डेटा प्राप्त करने की स्थिति में, डिकोडिंग एक badarg त्रुटि के साथ विफल हो badarg है।

यह प्रत्यक्ष रूप से नए परमाणुओं के निर्माण को रोकता है, नए परमाणुओं का निर्माण अप्रत्यक्ष रूप से (जैसा कि वे कुछ संरचनाओं में एम्बेडेड हैं, जैसे कि प्रक्रिया पहचानकर्ता, रेफ, और फन), और नए बाहरी फ़ंक्शन संदर्भों का निर्माण। उन संसाधनों में से कोई भी कचरा एकत्र नहीं किया जाता है, इसलिए उनमें से अनियंत्रित निर्माण उपलब्ध स्मृति को समाप्त कर सकता है।

> binary_to_term(<<131,100,0,5,"hello">>, [safe]).
** exception error: bad argument
> hello.
hello
> binary_to_term(<<131,100,0,5,"hello">>, [safe]).
hello
used

रिटर्न वैल्यू को {Term, Used} जहां Used बाइट की संख्या वास्तव में Binary से पढ़ी जाती है।

> Input = <<131,100,0,5,"hello","world">>.
<<131,100,0,5,104,101,108,108,111,119,111,114,108,100>>
> {Term, Used} = binary_to_term(Input, [used]).
{hello, 9}
> split_binary(Input, Used).
{<<131,100,0,5,104,101,108,108,111>>, <<"world">>}

विफलता: अगर safe निर्दिष्ट है और असुरक्षित डेटा को डिकोड किया गया है तो badarg

term_to_binary/1 , binary_to_term/1 , और list_to_existing_atom/1

bit_size (Bitstring) -> पूर्णांक ()> = 0

प्रकार

एक पूर्णांक देता है जो Bitstring बिट्स में आकार है, उदाहरण के लिए:

> bit_size(<<433:16,3:3>>).
19
> bit_size(<<1,2,3>>).
24

गार्ड परीक्षण में अनुमति है।

bitstring_to_list (बिटस्ट्रिंग) -> [बाइट () | bitstring ()]

प्रकार

Bitstring के बाइट्स के अनुरूप पूर्णांक की एक सूची देता है। यदि बाइनरी में बिट्स की संख्या 8 से विभाज्य नहीं है, तो सूची का अंतिम तत्व एक बिटस्ट्रिंग है जिसमें शेष 1-7 बिट्स हैं।

erlang: bump_reductions (कटौती) -> सच

प्रकार

यह कार्यान्वयन-निर्भर फ़ंक्शन कॉलिंग प्रक्रिया के लिए कमी काउंटर को बढ़ाता है। बीम एमुलेटर में, कमी काउंटर आमतौर पर प्रत्येक फ़ंक्शन और बीआईएफ कॉल के लिए एक से बढ़ जाता है। एक संदर्भ स्विच को मजबूर किया जाता है जब काउंटर एक प्रक्रिया के लिए अधिकतम कटौती तक पहुंच जाता है (2000 में एर्लांग / ओटीपी आर 1212 में कटौती)।

चेतावनी

इस बीआईएफ को पूर्व चेतावनी के बिना बीम मशीन के भविष्य के संस्करण में हटाया जा सकता है। इसे अन्य एरलांग कार्यान्वयन में लागू किए जाने की संभावना नहीं है।

बाइट_साइज़ (बिटस्ट्रिंग) -> पूर्णांक ()> = 0

प्रकार

एक पूर्णांक देता है जो Bitstring को शामिल करने के लिए आवश्यक बाइट्स की संख्या है। यही है, यदि Bitstring में बिट्स की संख्या 8 से विभाज्य नहीं है, तो परिणामस्वरूप बाइट्स की संख्या गोल है । उदाहरण:

> byte_size(<<433:16,3:3>>).
3
> byte_size(<<1,2,3>>).
3

गार्ड परीक्षण में अनुमति है।

erlang: Cancel_timer (टाइमर) -> परिणाम

प्रकार

एक टाइमर रद्द। कॉलिंग erlang:cancel_timer(TimerRef, []) समान erlang:cancel_timer(TimerRef, [])

erlang: Cancel_timer (टाइमर, विकल्प) -> परिणाम | ठीक

प्रकार

एक टाइमर को रद्द करता है जिसे erlang:start_timer द्वारा बनाया गया है erlang:start_timer या erlang:send_after TimerRef टाइमर की पहचान करता है, और BIF द्वारा टाइमर बनाया गया था।

Option s:

{async, Async}

रद्द करने के लिए अतुल्यकालिक अनुरोध। Async false को डिफॉल्ट करता false , जिसके कारण रद्दीकरण को सिंक्रोनाइज़ किया जाता है। जब Async को true सेट किया जाता true , तो रद्द किए गए ऑपरेशन को अतुल्यकालिक रूप से निष्पादित किया जाता है। यही है, cancel_timer() टाइमर को प्रबंधित करने वाली टाइमर सेवा को रद्द करने के लिए एक अतुल्यकालिक अनुरोध भेजता है, और फिर ok लौटता है।

{info, Info}

रद्द करने के Result के बारे में जानकारी का अनुरोध करता है। Info true निर्भर करती true , जिसका अर्थ है कि Result दिया गया है। जब Info false सेट की जाती false , तो रद्द करने के परिणाम के बारे में कोई जानकारी नहीं दी जाती है।

  • जब Async false : यदि Info true , तो Result erlang:cancel_timer() द्वारा वापस किया जाता है erlang:cancel_timer() । अन्यथा ok है।

  • जब Async true : यदि Info true , तो erlang:cancel_timer() के कॉलर को फॉर्म {cancel_timer, TimerRef, Result} पर एक संदेश भेजा जाता है erlang:cancel_timer() जब रद्द ऑपरेशन किया गया है, अन्यथा कोई संदेश नहीं भेजा जाता है।

अधिक Option भविष्य में जोड़े जा सकते हैं।

यदि Result पूर्णांक है, तो यह मिलीसेकेंड में उस समय का प्रतिनिधित्व करता है जब तक कि रद्द किए गए टाइमर की समय सीमा समाप्त नहीं हो जाती।

यदि Result false , तो टाइमर टाइमर के अनुरूप टाइमर नहीं मिल सकता है। यह या तो हो सकता है क्योंकि टाइमर समाप्त हो गया था, पहले से ही रद्द कर दिया गया था, या क्योंकि TimerRef कभी भी टाइमर के अनुरूप नहीं था। भले ही टाइमर समाप्त हो गया था, यह आपको नहीं बताता है कि क्या टाइम-आउट संदेश अभी तक अपने गंतव्य पर आ गया है।

ध्यान दें

टाइमर को प्रबंधित करने वाली टाइमर सेवा को शेड्यूलर की तुलना में किसी अन्य शेड्यूलर के साथ सह-स्थित किया जा सकता है जिसे कॉलिंग प्रक्रिया निष्पादित कर रही है। यदि ऐसा है, तो टाइमर सेवा के साथ संचार स्थानीय समय की तुलना में अधिक समय लेता है। यदि कॉलिंग प्रक्रिया महत्वपूर्ण पथ में है, और इस ऑपरेशन के परिणाम की प्रतीक्षा करते समय अन्य चीजें कर सकते हैं, या ऑपरेशन के परिणाम में कोई दिलचस्पी नहीं है, तो आप विकल्प {async, true} का उपयोग करना चाहते हैं। यदि विकल्प {async, false} , तो कॉल प्रक्रिया तब तक अवरुद्ध हो जाती है जब तक ऑपरेशन नहीं किया गया हो।

erlang:send_after भी देखें erlang:send_after , erlang:start_timer , और erlang:read_timer/2

छत (संख्या) -> पूर्णांक ()

प्रकार

Number से कम नहीं सबसे छोटा पूर्णांक देता है। उदाहरण के लिए:

> ceil(5.5).
6

गार्ड परीक्षण में अनुमति है।

check_old_code (मॉड्यूल) -> बूलियन ()

प्रकार

यदि Module में पुराना कोड है, तो true , अन्यथा false

code(3) भी देखें code(3)

check_process_code (Pid, मॉड्यूल) -> CheckResult

प्रकार

check_process_code(Pid,Module, []) समान ही।

check_process_code (Pid, Module, OptionList) -> CheckResult | async

प्रकार

जाँचता है कि क्या Pid द्वारा पहचानी गई नोड लोकल प्रक्रिया Module के लिए पुराने कोड को निष्पादित करती है।

Option s:

{allow_gc, boolean()}

निर्धारित करता है कि ऑपरेशन करते समय कचरा संग्रह की अनुमति है या नहीं। यदि {allow_gc, false} पास हो जाता है, और ऑपरेशन के परिणाम को निर्धारित करने के लिए एक कचरा संग्रह की आवश्यकता होती है, तो ऑपरेशन निरस्त कर दिया जाता है (नीचे दिए गए CheckResult पर जानकारी देखें)। डिफ़ॉल्ट कचरा संग्रहण, अर्थात, {allow_gc, true}

{async, RequestId}

फ़ंक्शन check_process_code/3 अनुरोध भेजे जाने के तुरंत बाद मूल्य async लौटाता है। जब अनुरोध संसाधित किया गया है, तो इस फ़ंक्शन को कहा जाने वाला प्रक्रिया फॉर्म {check_process_code, RequestId, CheckResult} पर एक संदेश पारित किया जाता है।

यदि Pid self() बराबर है self() , और कोई async विकल्प पारित नहीं हुआ है, तो ऑपरेशन एक ही बार में किया जाता है। अन्यथा ऑपरेशन के लिए एक अनुरोध Pid द्वारा पहचानी गई प्रक्रिया को भेजा जाता है, और जब उचित होता है। यदि कोई async विकल्प पारित नहीं हुआ है, तो CheckResult उपलब्ध होने तक कॉलर को ब्लॉक कर देता है और उसे वापस किया जा सकता है।

CheckResult अनुरोध के परिणाम के बारे में बताता है:

true

Pid द्वारा पहचानी गई प्रक्रिया Module के लिए पुराने कोड को निष्पादित करती है। यही है, प्रक्रिया की वर्तमान कॉल इस मॉड्यूल के लिए पुराने कोड को निष्पादित करती है, या प्रक्रिया में इस मॉड्यूल के लिए पुराने कोड का संदर्भ होता है, या प्रक्रिया में ऐसे फन होते हैं जो इस मॉड्यूल के लिए पुराने कोड का संदर्भ देते हैं।

false

Pid द्वारा पहचानी गई प्रक्रिया Module के लिए पुराने कोड को निष्पादित नहीं करती है।

aborted

ऑपरेशन को रद्द कर दिया गया था, क्योंकि ऑपरेशन के परिणाम को निर्धारित करने के लिए प्रक्रिया को इकट्ठा करने के लिए कचरा इकट्ठा करने की आवश्यकता थी, और ऑपरेशन को विकल्प {allow_gc, false} द्वारा पारित करने का अनुरोध किया गया था।

ध्यान दें

ईआरटीएस संस्करण 8. * तक, पुराने कोड के सभी प्रकार के संदर्भों के लिए चेक प्रोसेस कोड ऑपरेशन चेक। यही है, प्रत्यक्ष संदर्भ (उदाहरण के लिए प्रक्रिया स्टैक पर पते), अप्रत्यक्ष संदर्भ (प्रक्रिया संदर्भ में fun एस), और कोड में शाब्दिक संदर्भ।

ईआरटीएस संस्करण 9.0 के रूप में, चेक प्रक्रिया कोड ऑपरेशन केवल कोड के सीधे संदर्भ के लिए जांच करता है। fun एस के जरिए अप्रत्यक्ष संदर्भों को नजरअंदाज किया जाएगा। यदि इस तरह के fun एस मौजूद हैं और पुराने कोड के शुद्ध होने के बाद उपयोग किए जाते हैं, तो एक अपवाद उपयोग पर उठाया जाएगा (वैसे ही जब पर्स के बाद की प्रक्रिया के द्वारा fun प्राप्त होता है)। बाद के स्तर पर (नकल) साहित्य का ध्यान रखा जाएगा। यह व्यवहार OTS संस्करण 8.1 के रूप में सक्षम किया जा सकता है जब building OTP , और स्वचालित रूप से सक्षम किया जाएगा यदि गंदा अनुसूचक समर्थन सक्षम है।

code(3) भी देखें code(3)

विफलताएं:

badarg
यदि Pid एक नोड स्थानीय प्रक्रिया पहचानकर्ता नहीं है।
badarg
यदि Module एक परमाणु नहीं है।
badarg
यदि OptionList विकल्पों की एक अमान्य सूची है।
erlang: Convert_time_unit (समय, FromUnit, ToUnit) -> रूपांतरित समय

प्रकार

Time यूनिट से टाइम यूनिट के Time मान को FromUnit टाइम यूनिट के संगत FromUnit Time मान में परिवर्तित करता है। फर्श फ़ंक्शन का उपयोग करके परिणाम को गोल किया जाता है।

चेतावनी

समय इकाइयों के बीच रूपांतरण करते समय आप सटीकता और सटीकता खो सकते हैं। इस तरह के नुकसान को कम करने के लिए, सभी डेटा को native समय इकाई में एकत्रित करें और अंतिम परिणाम पर रूपांतरण करें।

erlang: crc32 (डेटा) -> पूर्णांक ()> = 0

प्रकार

Data लिए crc32 (IEEE 802.3 शैली) चेकसम की गणना और रिटर्न करता है।

erlang: crc32 (OldCrc, Data) -> पूर्णांक ()> = 0

प्रकार

Data के चेकसम के साथ पिछले चेकसम, OldCrc संयोजन से crc32 चेकसम की गणना जारी OldCrc

निम्नलिखित कोड:

X = erlang:crc32(Data1),
Y = erlang:crc32(X,Data2).

इस के रूप में Y लिए एक ही मूल्य प्रदान करता है:

Y = erlang:crc32([Data1,Data2]).
erlang: crc32_combine (FirstCrc, SecondCrc, SecondSize) ->
पूर्णांक ()> = 0

प्रकार

दो पहले से गणना की गई crc32 चेकसम को मिलाता है। इस अभिकलन को दूसरे चेकसम के लिए ज्ञात ऑब्जेक्ट ऑब्जेक्ट के आकार की आवश्यकता होती है।

निम्नलिखित कोड:

Y = erlang:crc32(Data1),
Z = erlang:crc32(Y,Data2).

Z को समान मान प्रदान करता है:

X = erlang:crc32(Data1),
Y = erlang:crc32(Data2),
Z = erlang:crc32_combine(X,Y,iolist_size(Data2)).
दिनांक () -> दिनांक

प्रकार

वर्तमान दिनांक को {Year, Month, Day} रूप में लौटाता है।

समय क्षेत्र और डेलाइट सेविंग टाइम सुधार अंतर्निहित OS पर निर्भर करता है। उदाहरण:

> date().
{1995,2,19}
erlang: decode_packet (प्रकार, बिन, विकल्प) ->
{ठीक है, पैकेट, बाकी} |
{अधिक, लंबाई} |
{त्रुटि, कारण}

प्रकार

Type द्वारा निर्दिष्ट पैकेट प्रोटोकॉल के अनुसार बाइनरी Bin डिकोड करता है। विकल्प {packet,Type}. साथ सॉकेट्स द्वारा किए गए पैकेट हैंडलिंग के समान {packet,Type}.

यदि एक पूरा पैकेट Bin में समाहित है, तो यह बाइनरी के शेष के साथ {ok,Packet,Rest} रूप में वापस आ जाता है।

यदि Bin में पूरा पैकेट नहीं है, तो {more,Length} वापस कर दी जाती है। Length या तो पैकेट के अपेक्षित कुल आकार की है, या अपेक्षित पैकेट आकार अज्ञात होने पर undefined है। decode_packet को फिर से और अधिक डेटा के साथ जोड़ा जा सकता है।

यदि पैकेट प्रोटोकॉल प्रारूप के अनुरूप नहीं है, तो {error,Reason} को लौटा दिया जाता है।

Type s:

raw | 0

कोई पैकेट हैंडलिंग नहीं किया जाता है। पूरे बाइनरी को तब तक लौटाया जाता है जब तक कि वह खाली न हो।

1 | 2 | 4

पैकेट में एक हेडर होता है, जो पैकेट में बाइट्स की संख्या निर्दिष्ट करता है, उसके बाद बाइट्स की संख्या। हेडर की लंबाई एक, दो या चार बाइट्स हो सकती है; बाइट्स का क्रम बड़ा-एंडियन है। पैकेट वापस आने पर हेडर को उतार दिया जाता है।

line

एक पैकेट एक सीमांकित बाइट द्वारा समाप्त की जाने वाली रेखा है, डिफ़ॉल्ट रूप से लैटिन -1 न्यूलाइन वर्ण है। जब तक लाइन को लाइन लाइन विकल्प के अनुसार छोटा नहीं किया जाता तब तक सीमांकित बाइट को लौटे पैकेट में शामिल किया जाता है।

asn1 | cdr | sunrm | fcgi | tpkt

हेडर को छीन नहीं लिया जाता है।

पैकेट प्रकार के अर्थ इस प्रकार हैं:

asn1 - ASN.1 BER
sunrm - Sun का RPC एन्कोडिंग
cdr - CORBA (GIOP 1.1)
fcgi - फास्ट सीजीआई
tpkt - TPKT प्रारूप [RFC1006]
http | httph | http_bin | httph_bin

हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल। पैकेट को पहले वर्णित HttpPacket अनुसार प्रारूप के साथ लौटाया जाता है। एक पैकेट या तो एक अनुरोध है, एक प्रतिक्रिया, एक हेडर या हेडर मार्क का अंत है। अमान्य पंक्तियों को HttpError रूप में लौटाया जाता है।

मान्यता प्राप्त अनुरोध के तरीके और हेडर फ़ील्ड परमाणुओं के रूप में वापस आ जाते हैं। अन्य को तार के रूप में लौटाया जाता है। गैर-मान्यता प्राप्त हेडर फ़ील्ड के स्ट्रिंग्स को पहले कैपिटल अक्षरों के साथ और हाइफ़न वर्णों के बाद स्वरूपित किया जाता है, उदाहरण के लिए, "Sec-Websocket-Key"

HttpRequest या HttpResponse अपेक्षित होने पर प्रोटोकॉल प्रकार http केवल पहली पंक्ति के लिए उपयोग किया जाता है। http_eoh वापस http_eoh तक HttpHeader s प्राप्त करने के लिए निम्नांकित कॉल्स का उपयोग करने के लिए निम्नांकित कॉल्स का उपयोग httph है, जो हेडर के अंत और किसी भी निम्न संदेश बॉडी की शुरुआत को चिह्नित करता है।

सूचियों के बजाय वेरिएंट http_bin और httph_bin रिटर्न स्ट्रिंग्स ( HttpString ) को बायनेरिज़ के रूप में।

विकल्प:

{packet_size, integer() >= 0}

पैकेट बॉडी का अधिकतम अनुमत आकार सेट करता है। यदि पैकेट हेडर इंगित करता है कि पैकेट की लंबाई अधिकतम अनुमत लंबाई से अधिक है, तो पैकेट को अमान्य माना जाता है। डिफ़ॉल्ट 0, जिसका अर्थ है कोई आकार सीमा नहीं।

{line_length, integer() >= 0}

पैकेट प्रकार की line , संकेतित लंबाई की तुलना में लंबी लाइनें छंटनी की जाती हैं।

विकल्प line_length http* पैकेट प्रकारों के लिए भी लागू होता है विकल्प के लिए एक उपनाम के रूप में packet_size यदि packet_size ही सेट नहीं है। यह उपयोग केवल पिछड़ी संगतता के लिए है।

{line_delimiter, 0 =< byte() =< 255}

पैकेट प्रकार line , परिसीमन बाइट सेट करता है। डिफ़ॉल्ट लैटिन -1 वर्ण $\n

उदाहरण:

> erlang:decode_packet(1,<<3,"abcd">>,[]).
{ok,<<"abc">>,<<"d">>}
> erlang:decode_packet(1,<<5,"abcd">>,[]).
{more,6}
erlang: delete_element (इंडेक्स, Tuple1) -> Tuple2

प्रकार

1..tuple_size (Tuple1)

उदाहरण के लिए, Tuple1 से हटाए गए Index तत्व के साथ एक नया टपल लौटाता है:

> erlang:delete_element(2, {one, two, three}).
{one,three}
delete_module (मॉड्यूल) -> सच | अपरिभाषित

प्रकार

Module के लिए वर्तमान कोड पुराना कोड बन जाता है और निर्यात तालिका से इस मॉड्यूल के सभी संदर्भ हटा देता है। मॉड्यूल मौजूद नहीं है, तो undefined लौटाता है, अन्यथा true

चेतावनी

यह BIF कोड सर्वर ( code(3) देखें code(3) ) के लिए अभिप्रेत है और इसका उपयोग कहीं और नहीं किया जाना है।

विफलता: अगर पहले से ही Module का एक पुराना संस्करण है तो badarg

डेमनीटर (मॉनिटररिफ) -> सच

प्रकार

यदि MonitorRef एक संदर्भ है कि कॉलिंग प्रक्रिया monitor/2 को कॉल करके प्राप्त होती है, तो यह मॉनिटरिंग बंद हो जाती है। यदि निगरानी पहले से ही बंद है, तो कुछ भी नहीं होता है।

एक बार जब demonitor(MonitorRef) वापस आ जाता है, तो यह गारंटी दी जाती है कि मॉनिटर के कारण कोई {'DOWN', MonitorRef, _, _, _} संदेश भविष्य में कॉलर मैसेज कतार में नहीं रखा जाएगा। हालाँकि, कॉल से पहले कॉलर संदेश कतार में एक {'DOWN', MonitorRef, _, _, _} संदेश रखा जा सकता है। इसलिए आमतौर पर निगरानी बंद करने के बाद संदेश कतार से इस तरह के 'DOWN' संदेश को हटाने की सलाह दी जाती है। demonitor(MonitorRef, [flush]) का उपयोग demonitor(MonitorRef) बजाय किया जा सकता है यदि यह सफाई चाहता है।

ध्यान दें

एर्लैंग / ओटीपी आर 11 बी (ईआरटीएस 5.5) demonitor/1 से पहले पूरी तरह से अतुल्यकालिक रूप से व्यवहार किया गया है, अर्थात, मॉनिटर तब तक सक्रिय था जब तक कि "डेनिटर सिग्नल" निगरानी इकाई तक नहीं पहुंच जाता। इसका एक अवांछनीय प्रभाव था। मॉनीटर की वजह से आपको DOWN मैसेज मिलने की गारंटी कब मिली, यह आप कभी नहीं जान सकते।

वर्तमान व्यवहार को दो संयुक्त अभियानों के रूप में देखा जा सकता है: अतुल्यकालिक रूप से मॉनिटर किए गए इकाई को एक "डेमोनिटर सिग्नल" भेजें और मॉनिटर के किसी भी भविष्य के परिणामों को अनदेखा करें।

विफलता: यह एक त्रुटि है अगर MonitorRef किसी अन्य प्रक्रिया द्वारा शुरू की गई निगरानी को संदर्भित करता है। ऐसे सभी मामले जांच के लिए सस्ते नहीं हैं। यदि चेकिंग सस्ता है, तो कॉल badarg साथ विफल हो badarg , उदाहरण के लिए यदि MonitorRef एक दूरस्थ संदर्भ है।

डेमनीटर (मॉनीटर रीफ, ऑप्शनलिस्ट) -> बूलियन ()

प्रकार

जब तक info OptionList का हिस्सा न हो, लौटाया गया मान true OptionList

demonitor(MonitorRef, []) demonitor(MonitorRef) बराबर है।

Option s:

flush

हटाता है (एक) {_, MonitorRef, _, _, _} संदेश, अगर वहाँ एक है, तो कॉलर संदेश कतार से निगरानी के बाद रोक दिया गया है।

कॉलिंग demonitor(MonitorRef, [flush]) निम्नलिखित के बराबर है, लेकिन अधिक कुशल:

demonitor(MonitorRef),
receive
    {_, MonitorRef, _, _, _} ->
        true
after 0 ->
        true
end
info

लौटाया गया मान निम्न में से एक है:

true

मॉनिटर पाया गया और हटा दिया गया। इस स्थिति में, इस मॉनीटर के अनुरूप कोई 'DOWN' संदेश नहीं दिया गया है और वितरित नहीं किया जाएगा।

false

मॉनिटर नहीं मिला और उसे हटाया नहीं जा सका। यह शायद इसलिए क्योंकि किसी ने पहले से ही कॉल मॉनिटर संदेश कतार में इस मॉनिटर के लिए एक 'DOWN' संदेश रखा है।

यदि विकल्प info को flush विकल्प के साथ जोड़ दिया जाता है, तो फ्लश की आवश्यकता होने पर false लौटा दी जाती है, अन्यथा true

ध्यान दें

भविष्य के रिलीज़ में अधिक विकल्प जोड़े जा सकते हैं।

विफलताएं:

badarg
यदि OptionList एक सूची नहीं है।
badarg
यदि Option एक अमान्य विकल्प है।
badarg
demonitor(MonitorRef) लिए समान विफलता।
disconnect_node (Node) -> बूलियन () | अवहेलना करना

प्रकार

एक नोड के वियोग को मजबूर करता है। यह नोड Node को प्रतीत होता है जैसे कि स्थानीय नोड दुर्घटनाग्रस्त हो गया है। यह BIF मुख्य रूप से Erlang नेटवर्क प्रमाणीकरण प्रोटोकॉल में उपयोग किया जाता है।

अगर वियोग सफल होता true तो true , अन्यथा false । यदि स्थानीय नोड जीवित नहीं है, तो ignored जाता है।

erlang: प्रदर्शन (शब्द) -> सच

प्रकार

मानक आउटपुट पर Term का पाठ प्रतिनिधित्व प्रिंट करता है।

चेतावनी

यह बीआईएफ केवल डिबगिंग के लिए है।

erlang: dist_ctrl_get_data (DHandle) -> डेटा | कोई नहीं

प्रकार

स्थानीय नोड से वितरण चैनल डेटा प्राप्त करें जो दूरस्थ नोड को पारित किया जाना है। वितरण चैनल की पहचान DHandle द्वारा की DHandle । यदि कोई डेटा उपलब्ध none है, तो परमाणु वापस none है। जब कोई डेटा erlang:dist_ctrl_get_data_notification(DHandle) कॉल करके उपलब्ध हो तो एक संदेश द्वारा सूचित किया जा सकता है।

ध्यान दें

केवल DHandle द्वारा वितरित वितरण चैनल के लिए वितरण नियंत्रक के रूप में पंजीकृत प्रक्रिया को इस फ़ंक्शन को कॉल करने की अनुमति है।

इस फ़ंक्शन का उपयोग वितरण नियंत्रकों के रूप में प्रक्रियाओं का उपयोग करके एक वैकल्पिक वितरण वाहक को लागू करते समय किया जाता है। DHandle को कॉलबैक f_handshake_complete माध्यम से f_handshake_complete । अधिक जानकारी ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module के प्रलेखन में पाया जा सकता ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution ModuleERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module

erlang: dist_ctrl_get_data_notification (DHandle) -> ठीक है

प्रकार

सूचना का अनुरोध तब करें जब erlang:dist_ctrl_get_data(DHandle) का उपयोग करने के लिए अधिक डेटा उपलब्ध हो erlang:dist_ctrl_get_data(DHandle) द्वारा वितरण चैनल के लिए erlang:dist_ctrl_get_data(DHandle) । अधिक डेटा मौजूद होने पर, कॉल करने वाले को संदेश भेजा जाएगा dist_data । एक बार जब एक dist_data संदेश भेजा गया है, तब तक और अधिक dist_data संदेश नहीं भेजे जाएंगे जब तक dist_ctrl_get_data_notification/1 फ़ंक्शन को फिर से नहीं बुलाया जाएगा।

ध्यान दें

केवल DHandle द्वारा वितरित वितरण चैनल के लिए वितरण नियंत्रक के रूप में पंजीकृत प्रक्रिया को इस फ़ंक्शन को कॉल करने की अनुमति है।

इस फ़ंक्शन का उपयोग वितरण नियंत्रकों के रूप में प्रक्रियाओं का उपयोग करके एक वैकल्पिक वितरण वाहक को लागू करते समय किया जाता है। DHandle को कॉलबैक f_handshake_complete माध्यम से f_handshake_complete । अधिक जानकारी ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module के प्रलेखन में पाया जा सकता ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution ModuleERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module

erlang: dist_ctrl_input_handler (DHandle, InputHandler) -> ठीक है

प्रकार

DHandle द्वारा पहचाने गए वितरण चैनल के लिए एक वैकल्पिक इनपुट हैंडलर प्रक्रिया DHandle । एक बार इस फ़ंक्शन को कॉल करने के बाद, InputHandler एकमात्र प्रक्रिया है जिसे InputHandler erlang:dist_ctrl_put_data(DHandle, Data) को कॉल करने की अनुमति erlang:dist_ctrl_put_data(DHandle, Data) जिसमें DHandle इस वितरण चैनल की पहचान करता है।

ध्यान दें

केवल DHandle द्वारा वितरित वितरण चैनल के लिए वितरण नियंत्रक के रूप में पंजीकृत प्रक्रिया को इस फ़ंक्शन को कॉल करने की अनुमति है।

इस फ़ंक्शन का उपयोग वितरण नियंत्रकों के रूप में प्रक्रियाओं का उपयोग करके एक वैकल्पिक वितरण वाहक को लागू करते समय किया जाता है। DHandle को कॉलबैक f_handshake_complete माध्यम से f_handshake_complete । अधिक जानकारी ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module के प्रलेखन में पाया जा सकता ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution ModuleERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module

erlang: dist_ctrl_put_data (DHandle, Data) -> ठीक है

प्रकार

दूरस्थ नोड से स्थानीय नोड में वितरण चैनल डेटा वितरित करें।

ध्यान दें

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

इस फ़ंक्शन का उपयोग वितरण नियंत्रकों के रूप में प्रक्रियाओं का उपयोग करके एक वैकल्पिक वितरण वाहक को लागू करते समय किया जाता है। DHandle को कॉलबैक f_handshake_complete माध्यम से f_handshake_complete । अधिक जानकारी ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module के प्रलेखन में पाया जा सकता ERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution ModuleERTS User's Guide ➜ How to implement an Alternative Carrier for the Erlang Distribution ➜ Distribution Module

तत्व (एन, ट्यूपल) -> शब्द ()

प्रकार

1..tuple_size (टपल)

उदाहरण के लिए, N वें तत्व (1 से नंबरिंग) Tuple :

> element(2, {a, b, c}).
b

गार्ड परीक्षण में अनुमति है।

मिटा () -> [{कुंजी, वैल}]

प्रकार

उदाहरण के लिए प्रक्रिया शब्दकोश लौटाता है और हटाता है:

> put(key1, {1, 2, 3}),
put(key2, [a, b, c]),
erase().
[{key1,{1,2,3}},{key2,[a,b,c]}]
erase (की) -> Val | अपरिभाषित

प्रकार

वैल्यू की से जुड़े वैल्यू को लौटाता है और इसे प्रोसेस डिक्शनरी से हटा देता है। यदि कोई मान Key से संबद्ध नहीं है, तो undefined है। उदाहरण:

> put(key1, {merry, lambs, are, playing}),
X = erase(key1),
{X, erase(key1)}.
{{merry,lambs,are,playing},undefined}
त्रुटि (कारण) -> no_return ()

प्रकार

कॉलिंग प्रक्रिया के निष्पादन को कारण के साथ रोक देता है, जहां Reason कोई भी शब्द है। बाहर निकलने का कारण {Reason, Where} , जहां हाल ही में कहे जाने वाले कार्यों की सूची (वर्तमान में पहला कार्य) है। इस फ़ंक्शन का मूल्यांकन करने के कारण प्रक्रिया समाप्त हो जाती है, इसका कोई वापसी मूल्य नहीं है। उदाहरण:

> catch error(foobar).
{'EXIT',{foobar,[{shell,apply_fun,3,
                        [{file,"shell.erl"},{line,906}]},
                 {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,677}]},
                 {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,430}]},
                 {shell,exprs,7,[{file,"shell.erl"},{line,687}]},
                 {shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]},
                 {shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}]}}
त्रुटि (कारण, तर्क) -> no_return ()

प्रकार

कॉलिंग प्रक्रिया के निष्पादन को कारण के साथ रोक देता है, जहां Reason कोई भी शब्द है। बाहर निकलने का कारण {Reason, Where} , जहां हाल ही में कहे जाने वाले कार्यों की सूची (वर्तमान में पहला कार्य) है। Args को वर्तमान फ़ंक्शन के लिए तर्कों की सूची होने की उम्मीद है; बीम में इसका उपयोग शब्द में वर्तमान फ़ंक्शन के लिए तर्क प्रदान करने के लिए किया जाता है। इस फ़ंक्शन का मूल्यांकन करने के कारण प्रक्रिया समाप्त हो जाती है, इसका कोई वापसी मूल्य नहीं है।

बाहर निकलें (कारण) -> no_return ()

प्रकार

कॉल करने की प्रक्रिया को एक्जिट कारण के साथ रोक देता है Reason , जहां Reason कोई भी शब्द है। इस फ़ंक्शन का मूल्यांकन करने के कारण प्रक्रिया समाप्त हो जाती है, इसका कोई वापसी मूल्य नहीं है। उदाहरण:

> exit(foobar).
** exception exit: foobar
> catch exit(foobar).
{'EXIT',foobar}
बाहर निकलें (पीआईडी, कारण) -> सच

प्रकार

बाहर निकलने के संकेत के साथ बाहर निकलने का संकेत भेजता है, जिस प्रक्रिया या पोर्ट द्वारा पहचाना जाता है।

निम्न व्यवहार लागू होता है यदि normal या kill को छोड़कर Reason कोई भी शब्द है:

  • यदि Pid बाहर निकलने के लिए जाल नहीं है, तो Pid बाहर निकलने के कारण के साथ ही बाहर निकलता है Reason

  • यदि Pid बाहर निकल रहा है, तो बाहर निकलने के संकेत को संदेश में बदल {'EXIT', From, Reason} दिया जाता है और संदेश कतार में पहुंचा दिया जाता है Pid

  • From उस प्रक्रिया की प्रक्रिया पहचानकर्ता है जिसने निकास संकेत भेजा है। यह भी देखें process_flag/2

अगर Reason परमाणु है normal , Pid तो बाहर नहीं निकलता है। यदि यह बाहर निकल रहा है, तो बाहर निकलने का संकेत एक संदेश में बदल जाता है {'EXIT', From, normal} और इसकी संदेश कतार में पहुंचा दिया जाता है।

यदि Reason परमाणु है kill , अर्थात, यदि exit(Pid, kill) कहा जाता है, तो एक अयोग्य निकास संकेत भेजा जाता है Pid , जो बिना किसी कारण के बिना शर्त के बाहर निकल जाता है killed

erlang: external_size (शब्द) -> पूर्णांक ()> = 0

प्रकार

गणना करता है, एन्कोडिंग किए बिना, शब्द के लिए अधिकतम बाइट का आकार एरलंग बाहरी शब्द प्रारूप में एन्कोडेड है। निम्नलिखित शर्त हमेशा लागू होती है:

> Size1 = byte_size(term_to_binary(Term)),
> Size2 = erlang:external_size(Term),
> true = Size1 =< Size2.
true

यह एक कॉल के बराबर है:

erlang:external_size(Term, [])
erlang: external_size (टर्म, विकल्प) -> पूर्णांक ()> = 0

प्रकार

गणना करता है, एन्कोडिंग किए बिना, शब्द के लिए अधिकतम बाइट का आकार एरलंग बाहरी शब्द प्रारूप में एन्कोडेड है। निम्नलिखित शर्त हमेशा लागू होती है:

> Size1 = byte_size(term_to_binary(Term, Options)),
> Size2 = erlang:external_size(Term, Options),
> true = Size1 =< Size2.
true

विकल्प {minor_version, Version} निर्दिष्ट करता है कि कैसे फ़्लोट एन्कोड किए गए हैं। विस्तृत विवरण के लिए, देखें term_to_binary/2

फ्लोट (संख्या) -> फ्लोट ()

प्रकार

Number उदाहरण के लिए, एक फ्लोट में परिवर्तित करके एक फ्लोट लौटाता है :

> float(55).
55.0

गार्ड परीक्षण में अनुमति है।

ध्यान दें

यदि किसी गार्ड में शीर्ष स्तर पर उपयोग किया जाता है, तो यह परीक्षण करता है कि क्या तर्क एक अस्थायी बिंदु संख्या है; स्पष्टता के लिए, is_float/1 इसके बजाय का उपयोग करें ।

जब float/1 किसी अभिभावक में अभिव्यक्ति में प्रयोग किया जाता है, जैसे कि ' float(A) == 4.0 ', तो यह एक संख्या को पहले बताए अनुसार रूपांतरित करता है।

float_to_binary (फ्लोट) -> बाइनरी ()

प्रकार

के रूप में ही float_to_binary(Float,[{scientific,20}])

float_to_binary (फ्लोट, विकल्प) -> बाइनरी ()

प्रकार

Float फिक्स्ड दशमलव बिंदु स्वरूपण का उपयोग करने के पाठ प्रतिनिधित्व के लिए एक बाइनरी देता है । Options उसी तरह व्यवहार करता है float_to_list/2 । उदाहरण:

> float_to_binary(7.12, [{decimals, 4}]).
<<"7.1200">>
> float_to_binary(7.12, [{decimals, 4}, compact]).
<<"7.12">>
float_to_list (फ्लोट) -> स्ट्रिंग ()

प्रकार

के रूप में ही float_to_list(Float,[{scientific,20}])

float_to_list (फ्लोट, विकल्प) -> स्ट्रिंग ()

प्रकार

Float निश्चित दशमलव बिंदु स्वरूपण का उपयोग करने के पाठ प्रतिनिधित्व के अनुरूप एक स्ट्रिंग लौटाता है ।

उपलब्ध विकल्प:

  • यदि विकल्प decimals निर्दिष्ट किया जाता है, तो लौटाया गया मान Decimals दशमलव बिंदु के पिछले अधिकांश अंकों में होता है। यदि संख्या 256 बाइट्स के आंतरिक स्थिर बफर में फिट नहीं होती है, तो फ़ंक्शन फेंकता है badarg

  • यदि विकल्प compact निर्दिष्ट किया गया है, तो सूची के अंत में अनुगामी शून्य को काट दिया जाता है। यह विकल्प विकल्प के साथ मिलकर ही सार्थक है decimals

  • यदि विकल्प scientific निर्दिष्ट किया गया है, तो फ्लोट को Decimals परिशुद्धता के अंकों के साथ वैज्ञानिक संकेतन का उपयोग करके स्वरूपित किया जाता है ।

  • यदि Options है [] , तो फ़ंक्शन व्यवहार करता है float_to_list/1

उदाहरण:

> float_to_list(7.12, [{decimals, 4}]).
"7.1200"
> float_to_list(7.12, [{decimals, 4}, compact]).
"7.12"
मंजिल (संख्या) -> पूर्णांक ()

प्रकार

से बड़ा नहीं पूर्णांक देता है Number । उदाहरण के लिए:

> floor(-10.5).
-11

गार्ड परीक्षण में अनुमति है।

erlang: fun_info (मज़ा) -> [{आइटम, जानकारी}]

प्रकार

मस्ती के बारे में जानकारी के साथ एक सूची देता है Fun । प्रत्येक सूची तत्व एक टपल है। टुपल्स का क्रम अपरिभाषित है, और भविष्य के रिलीज में अधिक ट्यूपल्स को जोड़ा जा सकता है।

चेतावनी

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

दो प्रकार के फन्नों में थोड़ा अलग शब्दार्थ होता है:

  • द्वारा बनाई गई एक मज़ेदार को बाहरी मज़ा fun M:F/A कहा जाता है। इसे कॉल करना हमेशा मॉड्यूल के लिए नवीनतम कोड में फ़ंक्शन को एरिटी के साथ कॉल करेगा । ध्यान दें कि मौज मस्ती करने पर मॉड्यूल को लोड करने की भी आवश्यकता नहीं होती है। F A M M fun M:F/A

  • अन्य सभी फनों को स्थानीय कहा जाता है । जब एक स्थानीय मज़ा कहा जाता है, तो कोड का वही संस्करण जो मज़ा पैदा करता है उसे कहा जाता है (भले ही मॉड्यूल का नया संस्करण लोड किया गया हो)।

निम्नलिखित तत्व हमेशा स्थानीय और बाहरी दोनों प्रकारों के लिए सूची में मौजूद होते हैं:

{type, Type}

Type है local या external

{module, Module}

Module (एक परमाणु) मॉड्यूल नाम है।

यदि Fun एक स्थानीय मज़ा है, Module तो वह मॉड्यूल है जिसमें मज़ा परिभाषित किया गया है।

यदि Fun एक बाहरी मज़ा है, Module तो वह मॉड्यूल है जो मज़ा को संदर्भित करता है।

{name, Name}

Name (एक परमाणु) एक फ़ंक्शन नाम है।

यदि Fun एक स्थानीय मज़ा है, Name स्थानीय फ़ंक्शन का नाम है जो मज़ा को लागू करता है। (यह नाम संकलक द्वारा उत्पन्न किया गया था, और केवल सूचनात्मक उपयोग के लिए है। जैसा कि यह एक स्थानीय कार्य है, इसे सीधे नहीं कहा जा सकता है।) यदि कोई कोड वर्तमान में मनोरंजन के लिए लोड नहीं किया गया है, तो [] उसे एक परमाणु के बजाय लौटा दिया जाता है।

यदि Fun एक बाहरी मज़ा है, Name तो निर्यात किए गए फ़ंक्शन का नाम है जो मज़ा को संदर्भित करता है।

{arity, Arity}

Arity इस तर्क की संख्या है कि मज़ा किसके साथ कहा जाना है।

{env, Env}

Env (एक सूची) मनोरंजन के लिए पर्यावरण या मुफ्त चर है। बाहरी फ़न के लिए, लौटी हुई सूची हमेशा खाली होती है।

Fun स्थानीय होने पर निम्नलिखित तत्व केवल सूची में मौजूद होते हैं :

{pid, Pid}

Pid प्रक्रिया की प्रक्रिया पहचानकर्ता है जिसने मूल रूप से मज़ेदार बनाया है।

{index, Index}

Index (पूर्णांक) मॉड्यूल फन टेबल में एक इंडेक्स है।

{new_index, Index}

Index (पूर्णांक) मॉड्यूल फन टेबल में एक इंडेक्स है।

{new_uniq, Uniq}

Uniq (एक बाइनरी) इस मज़ा के लिए एक अनूठा मूल्य है। इसकी गणना पूरे मॉड्यूल के लिए संकलित कोड से की जाती है।

{uniq, Uniq}

Uniq (पूर्णांक) इस मज़ा के लिए एक अद्वितीय मूल्य है। एर्लैंग / ओटीपी आर 15 के रूप में, इस पूर्णांक की गणना पूरे मॉड्यूल के लिए संकलित कोड से की जाती है। एर्लैंग / ओटीपी आर 15 से पहले, यह पूर्णांक केवल मस्ती के शरीर पर आधारित था।

erlang: fun_info (मज़ा, आइटम) -> {आइटम, जानकारी}

प्रकार

के बारे में जानकारी देता है Fun द्वारा निर्दिष्ट अनुसार Item , के रूप में {Item,Info}

किसी भी मस्ती के लिए, Item परमाणुओं के किसी भी हो सकता है module , name , arity , env , या type

एक स्थानीय मस्ती के लिए, Item यह भी परमाणुओं से कोई भी हो सकता है index , new_index , new_uniq , uniq , और pid । बाहरी मज़ा के लिए, इनमें से किसी भी वस्तु का मूल्य हमेशा परमाणु होता है undefined

देख लो erlang:fun_info/1

erlang: fun_to_list (मज़ा) -> स्ट्रिंग ()

प्रकार

के पाठ प्रतिनिधित्व के अनुरूप एक स्ट्रिंग लौटाता है Fun

erlang: function_exported (मॉड्यूल, फ़ंक्शन, योग्यता) -> बूलियन ()

प्रकार

रिटर्न true अगर मॉड्यूल Module लोड किया गया है और इसमें एक निर्यात फ़ंक्शन शामिल है Function/Arity , या यदि कोई बीआईएफ (एक अंतर्निहित फ़ंक्शन सी में कार्यान्वित किया गया है), अन्यथा रिटर्न false

ध्यान दें

यह फ़ंक्शन false Erlang / OTP 18.0 से पहले BIF के लिए वापस आ जाता था ।

कचरा_ रंग () -> सच है

निष्पादन प्रक्रिया का एक तत्काल कचरा संग्रह मजबूर करता है। फ़ंक्शन का उपयोग तब तक नहीं किया जाना चाहिए जब तक कि उस पर ध्यान नहीं दिया गया हो (या संदेह करने के लिए अच्छे कारण हैं) कि सहज कचरा संग्रह बहुत देर से होगा या बिल्कुल नहीं।

चेतावनी

अनुचित उपयोग प्रणाली के प्रदर्शन को गंभीरता से कम कर सकता है।

कचरा_ रंग (पीआईडी) -> GCResult

प्रकार

के रूप में ही garbage_collect(Pid, [])

कचरा_ रंग (पीआईडी, विकल्प सूची) -> GCResult | async

प्रकार

कचरा द्वारा पहचाने गए नोड स्थानीय प्रक्रिया को इकट्ठा करता है Pid

Option :

{async, RequestId}
अनुरोध भेजे जाने के तुरंत बाद फ़ंक्शन garbage_collect/2 मान लौटाता है async । जब अनुरोध संसाधित किया गया है, तो इस फ़ंक्शन को कहा जाने वाला प्रक्रिया प्रपत्र पर एक संदेश पारित किया जाता है {garbage_collect, RequestId, GCResult}
{type, 'major' | 'minor'}
अनुरोध किए गए प्रकार के कचरा संग्रहकर्ता। डिफ़ॉल्ट मान है 'major' , जो एक पूर्ण जीसी ट्रिगर होगा। विकल्प 'minor' को एक संकेत माना जाता है और इसमें मामूली या प्रमुख जीसी रन हो सकता है।

यदि Pid बराबर है self() , और कोई async विकल्प पारित नहीं किया गया है, तो कचरा संग्रह एक बार में किया जाता है, अर्थात, कॉलिंग के समान garbage_collect/0 । अन्यथा कचरा संग्रहण के लिए एक अनुरोध द्वारा की गई प्रक्रिया को भेजा जाता है Pid , और उपयुक्त होने पर उसे संभाला जाएगा। यदि कोई async विकल्प पारित नहीं किया गया है, तो कॉलर तब तक GCResult उपलब्ध रहता है जब तक उपलब्ध न हो और उसे वापस किया जा सके।

GCResult कचरा संग्रहण अनुरोध के परिणाम के बारे में निम्नानुसार सूचित करता है:

true
द्वारा पहचानी गई प्रक्रिया Pid को कचरा एकत्र किया गया है।
false
कोई कचरा संग्रह नहीं किया गया था, क्योंकि Pid अनुरोध से पहले समाप्त की गई प्रक्रिया को संतुष्ट किया जा सकता है।

ध्यान दें कि एक ही कैवेट के लिए लागू होते हैं garbage_collect/0

विफलताएं:

badarg
यदि Pid एक नोड स्थानीय प्रक्रिया पहचानकर्ता नहीं है।
badarg
यदि OptionList विकल्पों की एक अमान्य सूची है।
get () -> [{Key, Val}]

प्रकार

{Key, Val} उदाहरण के लिए, टुपल्स की सूची के रूप में प्रक्रिया शब्दकोश लौटाता है :

> put(key1, merry),
put(key2, lambs),
put(key3, {are, playing}),
get().
[{key1,merry},{key2,lambs},{key3,{are,playing}}]
get (की) -> Val | अपरिभाषित

प्रकार

प्रक्रिया शब्दकोश में Val जुड़े मान को लौटाता है Key , या undefined यदि Key मौजूद नहीं है। उदाहरण:

> put(key1, merry),
put(key2, lambs),
put({any, [valid, term]}, {are, playing}),
get({any, [valid, term]}).
{are,playing}
erlang: get_cookie () -> कुकी | nocookie

प्रकार

स्थानीय नोड के जादू कुकी लौटाता है यदि नोड जीवित है, अन्यथा परमाणु nocookie

get_keys () -> [कुंजी]

प्रकार

उदाहरण के लिए, प्रक्रिया शब्दकोश में मौजूद सभी कुंजियों की सूची लौटाता है:

> put(dog, {animal,1}),
put(cow, {animal,2}),
put(lamb, {animal,3}),
get_keys().
[dog,cow,lamb]
get_keys (Val) -> [कुंजी]

प्रकार

Val उन उदाहरणों की सूची लौटाता है जो प्रक्रिया शब्दकोश में मूल्य से जुड़े हैं , उदाहरण के लिए:

> put(mary, {1, 2}),
put(had, {1, 2}),
put(a, {1, 2}),
put(little, {1, 2}),
put(dog, {1, 3}),
put(lamb, {1, 2}),
get_keys({1, 2}).
[mary,had,a,little,lamb]
erlang: get_stacktrace () -> [stack_item ()]

प्रकार

चेतावनी

erlang:get_stacktrace/0 वंचित है और भविष्य में रिलीज में काम करना बंद कर देगा।

erlang:get_stacktrace/0 कॉल स्टैक बैक-ट्रेस पुनर्प्राप्त करने के लिए उपयोग करने के बजाय , निम्न सिंटैक्स का उपयोग करें:

try Expr
catch
  Class:Reason:Stacktrace ->
   {Class,Reason,Stacktrace}
end

erlang:get_stacktrace/0 एक अपवाद के लिए कॉल स्टैक बैक-ट्रेस ( स्टैकट्रेस ) को पुनर्प्राप्त करता है जिसे केवल {Module,Function,Arity,Location} ट्यूपल्स की सूची के रूप में कॉलिंग प्रक्रिया में पकड़ा गया है । Arity पहली ट्यूपल में फ़ील्ड अपवाद के आधार पर एक एरिटी पूर्णांक के बजाय उस फ़ंक्शन कॉल की तर्क सूची हो सकती है।

यदि किसी प्रक्रिया में कोई अपवाद नहीं है, तो स्टैकट्रेस है [] । प्रक्रिया के लिए एक कोड परिवर्तन के बाद, स्टैकट्रेस को भी रीसेट किया जा सकता है []

स्टैकट्रेस ऑपरेटर catch रिटर्न के रूप में एक ही डेटा है, उदाहरण के लिए:

{'EXIT',{badarg,Stacktrace}} = catch abs(x)

Location दो-टुपल्स की एक (संभवतः खाली) सूची है जो फ़ंक्शन के स्रोत कोड में स्थान को इंगित कर सकती है। पहला तत्व एक परमाणु है जो दूसरे तत्व में जानकारी के प्रकार का वर्णन करता है। निम्नलिखित आइटम हो सकते हैं:

file
टपल का दूसरा तत्व एक स्ट्रिंग (वर्णों की सूची) है जो फ़ंक्शन के स्रोत फ़ाइल के फ़ाइल नाम का प्रतिनिधित्व करता है।
line
टपल का दूसरा तत्व स्रोत फ़ाइल में लाइन नंबर (एक पूर्णांक> 0) है जहां अपवाद हुआ या फ़ंक्शन को बुलाया गया था।
चेतावनी

डेवलपर्स को केवल डिबगिंग उद्देश्यों के लिए स्टैकट्रेस प्रविष्टियों पर भरोसा करना चाहिए।

VM पूंछ कॉल अनुकूलन करता है, जो स्टैकट्रेस में नई प्रविष्टियाँ नहीं जोड़ता है, और स्टैकट्रैक्स को एक निश्चित गहराई तक भी सीमित करता है। इसके अलावा, संकलक विकल्प, अनुकूलन और भविष्य के बदलाव स्टैकट्रेस प्रविष्टियों को जोड़ या हटा सकते हैं, जिससे किसी भी कोड का अनुमान होता है कि स्टैकट्रेस एक निश्चित क्रम में हो सकता है या इसमें विशिष्ट आइटम विफल हो सकते हैं।

इस नियम का एकमात्र अपवाद है, error:undef जो पहले स्टैकट्रेस प्रविष्टि के रूप में प्रयास फ़ंक्शन के मॉड्यूल, फ़ंक्शन और एरीटी को शामिल करने की गारंटी देता है।

यह भी देखें error/1 और error/2

group_leader () -> पिड ()

फ़ंक्शन का मूल्यांकन करने की प्रक्रिया के लिए समूह के नेता की प्रक्रिया पहचानकर्ता को लौटाता है।

प्रत्येक प्रक्रिया किसी न किसी प्रक्रिया समूह का सदस्य है और सभी समूहों में एक समूह नेता होता है । समूह से सभी I / O को समूह के नेता को दिखाया जाता है। जब एक नई प्रक्रिया को जन्म दिया जाता है, तो उसे स्पैनिंग प्रक्रिया के समान समूह का नेता मिल जाता है। प्रारंभ में, सिस्टम स्टार्टअप पर, init अपने स्वयं के समूह के नेता और सभी प्रक्रियाओं के समूह के नेता हैं।

group_leader (GroupLeader, Pid) -> सच

प्रकार

के समूह नेता को सेट करता Pid है GroupLeader । आमतौर पर, इसका उपयोग तब किया जाता है जब एक निश्चित शेल से शुरू की गई प्रक्रिया किसी अन्य समूह के नेता की तुलना में होती है init

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

आवेदन शुरू करने और रोकने के लिए भी देखें group_leader/0 और OTP design principles संबंधित।

पड़ाव () -> no_return ()

के रूप में ही halt(0, []) । उदाहरण:

> halt().
os_prompt%
पड़ाव (स्थिति) -> no_return ()

प्रकार

के रूप में ही halt(Status, []) । उदाहरण:

> halt(17).
os_prompt% echo $?
17
os_prompt%
पड़ाव (स्थिति, विकल्प) -> no_return ()

प्रकार

Status एक गैर-नकारात्मक पूर्णांक, एक स्ट्रिंग या परमाणु होना चाहिए abort । हर्ट्स एर्लांग रनटाइम सिस्टम। कोई वापसी मूल्य नहीं है। के आधार पर Status , निम्न होता है:

पूर्णांक ()
रनटाइम सिस्टम Status कॉलिंग वातावरण (OS) में स्थिति कोड के रूप में पूर्णांक मान से बाहर निकलता है ।
ध्यान दें

कई प्लेटफार्मों पर, ओएस केवल स्थिति कोड 0-255 का समर्थन करता है। उच्च बिट्स को साफ़ करके एक बहुत बड़ी स्थिति कोड को काट दिया जाता है।

स्ट्रिंग ()
एर्लैंग क्रैश डंप Status स्लोगन के रूप में निर्मित होता है । फिर रनटाइम सिस्टम स्टेटस कोड के साथ बाहर निकलता है 1 । 200 से अधिक वर्णों के होने पर स्ट्रिंग को छोटा कर दिया जाएगा।
ध्यान दें

ERTS 9.1 (OTP-20.1) से पहले केवल 0-255 रेंज में कोड बिंदुओं को स्ट्रिंग में स्वीकार किया गया था। अब कोई भी यूनिकोड स्ट्रिंग मान्य है।

abort
रनटाइम सिस्टम कोर डंप का उत्पादन करता है, अगर वह ओएस में सक्षम है।

पूर्णांक के लिए Status , एरलांग रनटाइम सिस्टम सभी बंदरगाहों को बंद कर देता है और बाहर निकलने से पहले अपने कार्यों को पूरा करने के लिए एसिंक्स थ्रेड को अनुमति देता है। ऐसे फ्लशिंग के बिना बाहर निकलने के लिए, के Option रूप में उपयोग करें {flush,false}

स्थिति string() और के लिए abort , विकल्प flush को नजरअंदाज कर दिया जाता है और फ्लशिंग नहीं किया जाता है।

HD (सूची) -> शब्द ()

प्रकार

List उदाहरण के लिए, पहला तत्व, का सिर लौटाता है :

> hd([1,2,3,4,5]).
1

गार्ड परीक्षण में अनुमति है।

असफलता: badarg अगर List खाली सूची है []

एरलैंग: हाइबरनेट (मॉड्यूल, फंक्शन, आर्ग्स) -> no_return ()

प्रकार

कॉलिंग प्रक्रिया को एक प्रतीक्षा स्थिति में डालता है जहाँ इसका मेमोरी आवंटन यथासंभव कम हो गया है। यह उपयोगी है अगर प्रक्रिया जल्द ही कोई संदेश प्राप्त करने की उम्मीद नहीं करती है।

जब संदेश भेजा जाता है तो प्रक्रिया जागृत होती है, और नियंत्रण कॉल स्टैक के साथ Module:Function निर्दिष्ट तर्कों के साथ फिर से शुरू हो जाता है Args , जिसका अर्थ है कि प्रक्रिया उस फ़ंक्शन को समाप्त कर देती है। इस प्रकार erlang:hibernate/3 इसके कॉलर पर कभी नहीं लौटता है।

यदि प्रक्रिया के पास अपनी संदेश पंक्ति में कोई संदेश है, तो प्रक्रिया तुरंत उसी तरह से जागृत हो जाती है, जैसा कि पहले बताया गया है।

अधिक तकनीकी शब्दों में, erlang:hibernate/3 प्रक्रिया के लिए कॉल स्टैक को त्याग देता है, और फिर कचरा प्रक्रिया को इकट्ठा करता है। इसके बाद, सभी लाइव डेटा एक निरंतर ढेर में हैं। फिर ढेर को उसी आकार में सिकुड़ा जाता है जैसा कि लाइव डेटा है जो इसे धारण करता है (भले ही वह आकार प्रक्रिया के लिए न्यूनतम हीप आकार से कम हो)।

यदि प्रक्रिया में लाइव डेटा का आकार न्यूनतम हीप आकार से कम है, तो प्रक्रिया के जागने के बाद होने वाला पहला कचरा संग्रह यह सुनिश्चित करता है कि ढेर का आकार न्यूनतम हीप आकार से छोटा नहीं आकार में बदल जाए।

ध्यान दें कि कॉल स्टैक को खाली करने का मतलब है कि किसी भी आसपास catch को हटा दिया गया है और हाइबरनेशन के बाद फिर से डाला जाना चाहिए। इसका एक प्रभाव यह है कि प्रक्रियाओं का उपयोग शुरू हुआ proc_lib (अप्रत्यक्ष रूप से, जैसे कि gen_server प्रक्रियाएं), proc_lib:hibernate/3 इसके बजाय इसका उपयोग करना है, यह सुनिश्चित करने के लिए कि प्रक्रिया के जागने पर अपवाद हैंडलर काम करना जारी रखे।

erlang: insert_element (इंडेक्स, Tuple1, टर्म) -> Tuple2

प्रकार

१.पुष्पी_सुइया (तुप्ले १) + १

टपल Term में स्थिति Index में सम्मिलित तत्व के साथ एक नया टपल लौटाता है Tuple1 । स्थिति Index और ऊपर से सभी तत्वों को नए टपल में एक कदम अधिक धकेल दिया जाता है Tuple2 । उदाहरण:

> erlang:insert_element(2, {one, two, three}, new).
{one,new,two,three}
integer_to_binary (पूर्णांक) -> बाइनरी ()

प्रकार

Integer उदाहरण के लिए, पाठ प्रतिनिधित्व के लिए एक द्विआधारी देता है :

> integer_to_binary(77).
<<"77">>
integer_to_binary (पूर्णांक, आधार) -> बाइनरी ()

प्रकार

Integer आधार के पाठ प्रतिनिधित्व के लिए एक द्विआधारी देता है Base , उदाहरण के लिए:

> integer_to_binary(1023, 16).
<<"3FF">>
पूर्णांक_सूची_सूची (पूर्णांक) -> स्ट्रिंग ()

प्रकार

Integer उदाहरण के लिए, टेक्स्ट प्रतिनिधित्व के अनुरूप स्ट्रिंग देता है :

> integer_to_list(77).
"77"
पूर्णांक_सूची_सूची (पूर्णांक, आधार) -> स्ट्रिंग ()

प्रकार

Integer आधार के पाठ प्रतिनिधित्व के अनुरूप एक स्ट्रिंग लौटाता है Base , उदाहरण के लिए:

> integer_to_list(1023, 16).
"3FF"
iolist_size (आइटम) -> पूर्णांक ()> = 0

प्रकार

एक पूर्णांक लौटाता है, जो बाइट्स में आकार है, बाइनरी का जो iolist_to_binary(Item) उदाहरण के लिए, का परिणाम होगा :

> iolist_size([1,2|<<3,4>>]).
4
iolist_to_binary (IoListOrBinary) -> बाइनरी ()

प्रकार

IoListOrBinary उदाहरण के लिए, पूर्णांक और बायनेरिज़ से बना बाइनरी लौटाता है :

> Bin1 = <<1,2,3>>.
<<1,2,3>>
> Bin2 = <<4,5>>.
<<4,5>>
> Bin3 = <<6>>.
<<6>>
> iolist_to_binary([Bin1,1,[2,3,Bin2],4|Bin3]).
<<1,2,3,1,2,3,4,5,4,6>>
erlang: iolist_to_iovec (IoListOrBinary) -> iovec()

प्रकार

एक iovec देता है जो पूर्णांक और बायनेरिज़ से बनाया जाता है IoListOrBinary

is_alive () -> बूलियन ()

रिटर्न true अगर स्थानीय नोड जीवित है (अर्थात, यदि नोड एक वितरित प्रणाली का हिस्सा हो सकता है), नहीं तो false

is_atom (टर्म) -> बूलियन ()

प्रकार

रिटर्न true अगर Term , एक परमाणु है अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_binary (शब्द) -> बूलियन ()

प्रकार

true यदि Term कोई बाइनरी है, तो वापस लौटाता है false

एक बाइनरी में हमेशा बाइट्स की एक पूरी संख्या होती है।

गार्ड परीक्षण में अनुमति है।

is_bitstring (शब्द) -> बूलियन ()

प्रकार

रिटर्न true अगर Term एक बिटस्ट्रिंग (एक बाइनरी सहित) है, अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_boolean (अवधि) -> बूलियन ()

प्रकार

true अगर Term परमाणु true या परमाणु false (जो एक बूलियन है) लौटाता है । अन्यथा false लौट आता false

गार्ड परीक्षण में अनुमति है।

erlang: is_builtin (मॉड्यूल, फ़ंक्शन, योग्यता) -> बूलियन ()

प्रकार

यह बीआईएफ क्रॉस-रेफरेंस टूल के बिल्डरों के लिए उपयोगी है।

रिटर्न true अगर Module:Function/Arity एक BIF सी में लागू किया, अन्यथा है false

is_float (टर्म) -> बूलियन ()

प्रकार

रिटर्न true अगर Term एक फ्लोटिंग पॉइंट नंबर है, अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_function (शब्द) -> बूलियन ()

प्रकार

लौटता है true अगर Term एक मजेदार है, अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_function (शब्द, योग्यता) -> बूलियन ()

प्रकार

रिटर्न true अगर Term एक मजेदार है जिसे Arity तर्कों की संख्या के साथ लागू किया जा सकता है , अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_integer (शब्द) -> बूलियन ()

प्रकार

रिटर्न true अगर Term पूर्णांक है, अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_list (शब्द) -> बूलियन ()

प्रकार

रिटर्न true अगर Term शून्य या अधिक तत्वों के साथ एक सूची है, अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_map (टर्म) -> बूलियन ()

प्रकार

true अगर Term नक्शा है, तो वापस कर दें false

गार्ड परीक्षण में अनुमति है।

is_map_key (कुंजी, मानचित्र) -> बूलियन ()

प्रकार

रिटर्न true अगर नक्शा Map होता है Key और रिटर्न false अगर यह शामिल नहीं है Key

{badmap,Map} यदि Map नक्शा नहीं है, तो कॉल अपवाद के साथ विफल हो जाता है।

उदाहरण:

> Map = #{"42" => value}.
#{"42" => value}
> is_map_key("42",Map).
true
> is_map_key(value,Map).
false
is_number (अवधि) -> बूलियन ()

प्रकार

रिटर्न true अगर Term एक पूर्णांक या एक अस्थायी बिंदु संख्या है। अन्यथा false लौट आता false

गार्ड परीक्षण में अनुमति है।

is_pid (टर्म) -> बूलियन ()

प्रकार

रिटर्न true अगर Term एक प्रक्रिया पहचानकर्ता है, अन्यथा false

गार्ड परीक्षण में अनुमति है।

is_port (अवधि) -> बूलियन ()

प्रकार

true यदि Term पोर्ट पहचानकर्ता है, तो वापस लौटाता है false

गार्ड परीक्षण में अनुमति है।

is_process_alive (Pid) -> बूलियन ()

प्रकार

Pid स्थानीय नोड पर एक प्रक्रिया का उल्लेख करना चाहिए।

रिटर्न true अगर प्रक्रिया मौजूद है और जीवित है, यानी बाहर नहीं है और बाहर नहीं निकला है। अन्यथा false लौट आता false

is_record (टर्म, रिकॉर्डटैग) -> बूलियन ()

प्रकार

रिटर्न true अगर Term एक ट्यूपल है और इसका पहला तत्व है RecordTag । अन्यथा false लौट आता false

ध्यान दें

आम तौर पर संकलक is_record/2 विशेष रूप से कॉल करता है । यह सत्यापित करने के लिए कोड का उत्सर्जन करता है कि Term एक टपल है, कि इसका पहला तत्व है RecordTag , और यह कि आकार सही है। हालांकि, अगर RecordTag शाब्दिक परमाणु नहीं है , तो is_record/2 इसके बजाय बीआईएफ को बुलाया जाता है और ट्यूपल के आकार को सत्यापित नहीं किया जाता है।

गार्ड परीक्षण में अनुमति है, अगर RecordTag एक शाब्दिक परमाणु है।

is_record (शब्द, रिकार्डटैग, आकार) -> बूलियन ()

प्रकार

RecordTag एक परमाणु होना चाहिए।

रिटर्न true अगर Term एक ट्यूपल है, तो इसका पहला तत्व है RecordTag , और इसका आकार है Size । अन्यथा false लौट आता false

गार्ड परीक्षणों में अनुमति दी जाती है यदि RecordTag एक शाब्दिक परमाणु है और Size एक शाब्दिक पूर्णांक है।

ध्यान दें

यह BIF पूर्णता के लिए प्रलेखित है। आमतौर पर is_record/2 इस्तेमाल किया जाना है।

is_reference (शब्द) -> बूलियन ()

प्रकार

true यदि Term संदर्भ है, तो वापस लौटाएं false

गार्ड परीक्षण में अनुमति है।

is_tuple (शब्द) -> बूलियन ()

प्रकार

रिटर्न true अगर Term , एक टपल है अन्यथा false

गार्ड परीक्षण में अनुमति है।

लंबाई (सूची) -> पूर्णांक ()> = 0

प्रकार

List उदाहरण के लिए, की लंबाई लौटाता है :

> length([1,2,3,4,5,6,7,8,9]).
9

गार्ड परीक्षण में अनुमति है।

लिंक (PidOrPort) -> सच है

प्रकार

कॉलिंग प्रक्रिया और एक अन्य प्रक्रिया (या पोर्ट) के बीच एक लिंक बनाता है PidOrPort , अगर पहले से ऐसा लिंक नहीं है। यदि कोई प्रक्रिया स्वयं के लिए लिंक बनाने का प्रयास करती है, तो कुछ भी नहीं किया जाता है। लौटता है true

यदि PidOrPort मौजूद नहीं है, तो बीआईएफ का व्यवहार इस बात पर निर्भर करता है कि कॉलिंग प्रक्रिया बाहर निकल रही है या नहीं (देखें process_flag/2 ):

  • यदि कॉलिंग प्रक्रिया बाहर नहीं जा रही है, और जाँच PidOrPort सस्ती है (जो कि PidOrPort स्थानीय है), link/1 कारण के साथ विफल हो जाती है noproc

  • अन्यथा, यदि कॉलिंग प्रक्रिया फंस रही है, और / या PidOrPort रिमोट है, तो link/1 रिटर्न मिलता है true , लेकिन noproc कॉलिंग प्रक्रिया को कारण के साथ एक निकास संकेत भेजा जाता है।

list_to_atom (स्ट्रिंग) -> परमाणु ()

प्रकार

वह परमाणु लौटाता है जिसका पाठ निरूपण है String

Erlang / OTP 20 से, String इसमें कोई भी यूनिकोड वर्ण हो सकता है। पहले के संस्करणों ने केवल आईएसओ-लैटिन -1 वर्णों की अनुमति दी थी क्योंकि कार्यान्वयन ने यूनिकोड वर्णों को 255 से ऊपर की अनुमति नहीं दी थी। परमाणुओं में यूनिकोड समर्थन के बारे में अधिक जानकारी के लिए, note on UTF-8 encoded atoms उपयोगकर्ता गाइड में "बाहरी शब्द प्रारूप" अनुभाग देखें ।

उदाहरण:

> list_to_atom("Erlang").
'Erlang'
list_to_binary (IoList) -> बाइनरी ()

प्रकार

IoList उदाहरण के लिए, पूर्णांक और बायनेरिज़ से बना बाइनरी लौटाता है :

> Bin1 = <<1,2,3>>.
<<1,2,3>>
> Bin2 = <<4,5>>.
<<4,5>>
> Bin3 = <<6>>.
<<6>>
> list_to_binary([Bin1,1,[2,3,Bin2],4|Bin3]).
<<1,2,3,1,2,3,4,5,4,6>>
list_to_bitstring (BitstringList) -> बिटस्ट्रिंग ()

प्रकार

एक बिटस्ट्रिंग लौटाता है जो पूर्णांकों और बिटस्ट्रिंग्स से बनाया जाता है BitstringList । (अंतिम पूंछ में BitstringList एक बिटस्ट्रिंग होने की अनुमति है।) उदाहरण:

> Bin1 = <<1,2,3>>.
<<1,2,3>>
> Bin2 = <<4,5>>.
<<4,5>>
> Bin3 = <<6,7:4>>.
<<6,7:4>>
> list_to_bitstring([Bin1,1,[2,3,Bin2],4|Bin3]).
<<1,2,3,1,2,3,4,5,4,6,7:4>>
list_to_existing_atom (स्ट्रिंग) -> परमाणु ()

प्रकार

वह परमाणु लौटाता है जिसका पाठ निरूपण होता है String , लेकिन केवल अगर वहां पहले से ही ऐसा परमाणु मौजूद है।

विफलता: badarg यदि पहले से ही एक परमाणु मौजूद नहीं है जिसका पाठ प्रतिनिधित्व है String

ध्यान दें

ध्यान दें कि संकलक दूर परमाणुओं का अनुकूलन कर सकता है। उदाहरण के लिए, कंपाइलर को फिर atom_to_list(some_atom) से लिखना होगा "some_atom" । यदि वह अभिव्यक्ति some_atom युक्त मॉड्यूल में परमाणु का एकमात्र उल्लेख है , तो परमाणु लोड नहीं किया जाएगा जब मॉड्यूल लोड किया जाता है, और बाद में कॉल list_to_existing_atom("some_atom") विफल होगा।

list_to_float (स्ट्रिंग) -> फ्लोट ()

प्रकार

String उदाहरण के लिए, जिसका पाठ प्रतिनिधित्व है फ्लोट लौटाता है :

> list_to_float("2.2017764e+0").
2.2017764

विफलता: badarg यदि String फ्लोट का खराब प्रतिनिधित्व होता है।

list_to_integer (स्ट्रिंग) -> पूर्णांक ()

प्रकार

एक पूर्णांक देता है जिसका पाठ प्रतिनिधित्व है String , उदाहरण के लिए:

> list_to_integer("123").
123

विफलता: badarg यदि String किसी पूर्णांक का खराब प्रतिनिधित्व है।

list_to_integer (स्ट्रिंग, आधार) -> पूर्णांक ()

प्रकार

एक पूर्णांक देता है जिसका आधार में पाठ प्रतिनिधित्व Base है String , उदाहरण के लिए:

> list_to_integer("3FF", 16).
1023

विफलता: badarg यदि String किसी पूर्णांक का खराब प्रतिनिधित्व है।

list_to_pid (स्ट्रिंग) -> pid ()

प्रकार

एक प्रक्रिया पहचानकर्ता देता है जिसका पाठ प्रतिनिधित्व एक String उदाहरण के लिए है:

> list_to_pid("<0.4.1>").
<0.4.1>

विफलता: badarg यदि String किसी प्रक्रिया पहचानकर्ता का खराब प्रतिनिधित्व है।

चेतावनी

यह BIF डिबगिंग के लिए अभिप्रेत है और इसका उपयोग एप्लिकेशन प्रोग्राम में नहीं किया जाता है

list_to_port (स्ट्रिंग) -> पोर्ट ()

प्रकार

एक बंदरगाह पहचानकर्ता लौटाता है जिसका पाठ प्रतिनिधित्व एक String उदाहरण के लिए है:

> list_to_port("#Port<0.4>").
#Port<0.4>

विफलता: badarg यदि String पोर्ट पहचानकर्ता का खराब प्रतिनिधित्व है।

चेतावनी

यह BIF डिबगिंग के लिए अभिप्रेत है और इसका उपयोग एप्लिकेशन प्रोग्राम में नहीं किया जाता है

list_to_ref (स्ट्रिंग) -> संदर्भ ()

प्रकार

एक संदर्भ देता है जिसका पाठ प्रतिनिधित्व एक String उदाहरण के लिए है:

> list_to_ref("#Ref<0.4192537678.4073193475.71181>").
#Ref<0.4192537678.4073193475.71181>

विफलता: badarg यदि String किसी संदर्भ का खराब प्रतिनिधित्व है।

चेतावनी

यह BIF डिबगिंग के लिए अभिप्रेत है और इसका उपयोग एप्लिकेशन प्रोग्राम में नहीं किया जाता है

list_to_tuple (सूची) -> tuple ()

प्रकार

List उदाहरण के लिए , एक टपल लौटाता है

> list_to_tuple([share, ['Ericsson_B', 163]]).
{share, ['Ericsson_B', 163]}

List किसी भी Erlang शब्द हो सकते हैं।

load_module (मॉड्यूल, बाइनरी) -> {मॉड्यूल, मॉड्यूल} | {त्रुटि, कारण}

प्रकार

यदि Binary मॉड्यूल के लिए ऑब्जेक्ट कोड होता है Module , तो यह BIF उस ऑब्जेक्ट कोड को लोड करता है। यदि मॉड्यूल के लिए कोड Module पहले से मौजूद है, तो सभी निर्यात संदर्भ बदल दिए जाते हैं, इसलिए वे नए लोड किए गए कोड को इंगित करते हैं। पहले से लोड किए गए कोड को पुराने कोड के रूप में सिस्टम में रखा जाता है, क्योंकि अभी भी उस कोड को निष्पादित करने की प्रक्रियाएं हो सकती हैं।

या तो लौटाता है {module, Module} , या {error, Reason} लोडिंग विफल रहता है। Reason निम्नलिखित में से एक है:

badfile
ऑब्जेक्ट कोड में Binary गलत प्रारूप है या ऑब्जेक्ट कोड में किसी अन्य मॉड्यूल के लिए कोड है Module
not_purged
Binary इसमें एक मॉड्यूल होता है जिसे लोड नहीं किया जा सकता क्योंकि इस मॉड्यूल के लिए पुराना कोड पहले से मौजूद है।
चेतावनी

यह BIF कोड सर्वर के लिए अभिप्रेत है (देखें code(3) ) और अन्यत्र उपयोग नहीं किया जाना है।

erlang: load_nif (पाथ, लोडइन्फो) -> ठीक है | त्रुटि

प्रकार

मॉड्यूल के लिए देशी कार्यान्वित फ़ंक्शंस (एनआईएफ) वाले एक गतिशील पुस्तकालय को भार और लिंक करता है। Path एक साझा करने योग्य ऑब्जेक्ट / डायनामिक लाइब्रेरी फ़ाइल का फ़ाइल पथ है, जो OS-निर्भर फ़ाइल एक्सटेंशन ( .so यूनिक्स के लिए और .dll विंडोज़ के लिए) घटाता है । ध्यान दें कि अधिकांश OS पर लाइब्रेरी का एक अलग नाम डिस्क पर होता है जब निफ़ का अपग्रेड किया जाता है। यदि नाम समान है, लेकिन सामग्री भिन्न है, तो इसके बजाय पुरानी लाइब्रेरी लोड की जा सकती है। एनआईएफ लाइब्रेरी को कैसे लागू किया जाए, इसकी जानकारी के लिए देखें erl_nif(3)

LoadInfo कोई भी शब्द हो सकता है इसे पुस्तकालय के आरंभ के भाग के रूप में पारित किया जाता है। एक अच्छा अभ्यास भविष्य कोड उन्नयन परिदृश्यों का समर्थन करने के लिए एक मॉड्यूल संस्करण संख्या शामिल करना है।

कॉल को सीधे उस मॉड्यूल के एरलांग कोड से load_nif/2 किया जाना चाहिए जो NIF लाइब्रेरी से संबंधित है। यह या तो वापस आता है , या यदि लोडिंग विफल हो जाती है। निम्नलिखित परमाणुओं में से एक है, जबकि एक मानव पठनीय स्ट्रिंग है जो विफलता के बारे में अधिक जानकारी दे सकता है: ok {error,{Reason,Text}} Reason Text

load_failed
OS NIF लाइब्रेरी लोड करने में विफल रहा।
bad_lib
लाइब्रेरी ने कॉल मॉड्यूल के एनआईएफ लाइब्रेरी के रूप में आवश्यकताओं को पूरा नहीं किया।
load | upgrade
संबंधित लाइब्रेरी कॉलबैक असफल रहा।
reload
इस मॉड्यूल उदाहरण के लिए पहले से ही एक NIF लाइब्रेरी भरी हुई है। reload ओटीपी 20 में पहले हटाए गए फीचर को हटा दिया गया था।
old_code
जिस load_nif/2 मॉड्यूल को अपग्रेड किया गया है उसके पुराने कोड से कॉल किया गया था; इसकी अनुमति नहीं है।
notsup
समर्थन की कमी। जैसे कि हाईपीई संकलित मॉड्यूल के लिए एनआईएफ लाइब्रेरी लोड करना।
erlang: भरी हुई () -> [मॉड्यूल]

प्रकार

सभी लोड किए गए एर्लांग मॉड्यूल (वर्तमान और पुराने कोड) की सूची लौटाता है, जिसमें पहले से लोड किए गए मॉड्यूल शामिल हैं।

यह भी देखें code(3)

erlang: स्थानीय समय () -> दिनांक समय

प्रकार

{{Year, Month, Day}, {Hour, Minute, Second}} उदाहरण के लिए , वर्तमान स्थानीय दिनांक और समय लौटाता है :

> erlang:localtime().
{{1996,11,6},{14,45,17}}

समय क्षेत्र और डेलाइट सेविंग टाइम सुधार अंतर्निहित OS पर निर्भर करता है।

erlang: localtime_to_universaltime (स्थानीय समय) -> सार्वभौमिक

प्रकार

यदि अंतर्निहित OS द्वारा समर्थित, स्थानीय दिनांक और समय को यूनिवर्सल टाइम कोऑर्डिनेटेड (UTC) में परिवर्तित करता है। अन्यथा कोई रूपांतरण नहीं किया जाता है और Localtime वापस कर दिया जाता है। उदाहरण:

> erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}).
{{1996,11,6},{13,45,17}}

विफलता: badarg यदि Localtime अमान्य दिनांक और समय को दर्शाता है।

erlang: localtime_to_universaltime (स्थानीय समय, IsDst) ->
सार्वभौमिक

प्रकार

यूनिवर्सल टाइम कोऑर्डिनेटेड (UTC) के रूप में स्थानीय दिनांक और समय को परिवर्तित करता है erlang:localtime_to_universaltime/1 , लेकिन कॉल करने वाला तय करता है कि डेलाइट सेविंग टाइम सक्रिय है या नहीं।

यदि IsDst == true , Localtime डेलाइट सेविंग टाइम के दौरान है, यदि IsDst == false यह नहीं है। यदि IsDst == undefined , अंतर्निहित ओएस अनुमान लगा सकता है, जो कॉलिंग के समान है erlang:localtime_to_universaltime(Localtime)

उदाहरण:

> erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, true).
{{1996,11,6},{12,45,17}}
> erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, false).
{{1996,11,6},{13,45,17}}
> erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, undefined).
{{1996,11,6},{13,45,17}}

विफलता: badarg यदि Localtime अमान्य दिनांक और समय को दर्शाता है।

make_ref () -> संदर्भ ()

रिटर्न ए unique reference । जुड़ा नोड्स के बीच संदर्भ अद्वितीय है।

चेतावनी

ज्ञात समस्या: जब एक नोड को एक ही नोड नाम के साथ कई बार पुनरारंभ किया जाता है, तो नए नोड पर बनाए गए संदर्भों को उसी नोड नाम के साथ पुराने नोड पर बनाए गए संदर्भ के लिए गलत किया जा सकता है।

erlang: make_tuple (Arity, InitialValue) -> ट्यूपल ()

प्रकार

उदाहरण के लिए Arity , जहां सभी तत्व हैं InitialValue , एक नया टपल बनाता है :

> erlang:make_tuple(4, []).
{[],[],[],[]}
erlang: make_tuple (Arity, DefaultValue, InitList) -> tuple ()

प्रकार

आकार का एक समूह बनाता है Arity , जहां प्रत्येक तत्व का मूल्य है DefaultValue , और फिर से मूल्यों में भर जाता है InitList । प्रत्येक सूची तत्व को InitList टू-टपल होना चाहिए, जहां पहला तत्व नए बनाए गए टपल में एक स्थिति है और दूसरा तत्व कोई भी शब्द है। यदि सूची में एक से अधिक बार स्थिति होती है, तो अंतिम घटना के अनुरूप शब्द का उपयोग किया जाता है। उदाहरण:

> erlang:make_tuple(5, [], [{2,ignored},{5,zz},{2,aa}]).
{[],aa,[],[],zz}
map_get (की, मैप) -> मान

प्रकार

यदि शामिल है के Value साथ जुड़े मान लौटाता है । Key Map Key

{badmap,Map} यदि Map नक्शा नहीं है, या {badkey,Key} अपवाद नहीं है, तो अपवाद अपवाद के साथ कॉल विफल रहता है Key

उदाहरण:

> Key = 1337,
  Map = #{42 => value_two,1337 => "value one","a" => 1},
  map_get(Key,Map).
"value one"
map_size (नक्शा) -> पूर्णांक ()> = 0

प्रकार

एक पूर्णांक लौटाता है, जो Map उदाहरण के लिए की -वैल्यू पेयर की संख्या है :

> map_size(#{a=>1, b=>2, c=>3}).
3

गार्ड परीक्षण में अनुमति है।

erlang: match_spec_test (MatchAgainst, MatchSpec, Type) ->
TestResult

प्रकार

टेस्ट मैच के विनिर्देशन का उपयोग ets:select/2 और के लिए कॉल में किया जाता है erlang:trace_pattern/3 । फ़ंक्शन "सिंटेक्टिक" शुद्धता के लिए मैच विनिर्देश दोनों का परीक्षण करता है और ऑब्जेक्ट के खिलाफ मैच विनिर्देश चलाता है। यदि मैच विनिर्देश में त्रुटियां हैं, तो टपल {error, Errors} लौटाया जाता है, जहां Errors मैच विनिर्देश के साथ गलत भाषा के प्राकृतिक विवरणों की एक सूची है।

यदि Type है table , तो मैच के लिए वस्तु एक टपल है। फ़ंक्शन तब वापस लौटता है {ok,Result,[],Warnings} , जहां Result वास्तविक ets:select/2 कॉल में परिणाम होता है , या false यदि मैच विनिर्देश ऑब्जेक्ट टपल से मेल नहीं खाता है।

यदि Type है trace , के खिलाफ मैच की वस्तु एक सूची है। फ़ंक्शन लौटता है {ok, Result, Flags, Warnings} , जहां Result निम्न में से एक है:

  • true यदि ट्रेस संदेश उत्सर्जित किया जाना है
  • false यदि ट्रेस संदेश उत्सर्जित नहीं किया जाना है
  • संदेश शब्द ट्रेस संदेश में जोड़ा जाएगा

Flags एक सूची है जिसमें सभी ट्रेस झंडे सक्षम हैं, वर्तमान में यह केवल है return_trace

यह एक उपयोगी डिबगिंग और परीक्षण उपकरण है, खासकर जब जटिल मिलान विनिर्देशों को लिखना।

यह भी देखें ets:test_ms/2

अधिकतम (टर्म 1, टर्म 2) -> अधिकतम

प्रकार

का सबसे बड़ा रिटर्न Term1 और Term2 । यदि शब्द समान हैं, Term1 तो लौटा दिया जाता है।

erlang: md5 (डेटा) -> डाइजेस्ट

प्रकार

एक MD5 संदेश को पचाता है Data , जहाँ से पचाने की लंबाई 128 बिट्स (16 बाइट्स) है। Data एक बाइनरी या छोटे पूर्णांक और बायनेरिज़ की सूची है।

MD5 के बारे में अधिक जानकारी के लिए, देखें RFC 1321 - The MD5 Message-Digest Algorithm

चेतावनी

MD5 संदेश-डाइजेस्ट एल्गोरिथ्म कोड-हस्ताक्षर या सॉफ़्टवेयर-अखंडता उद्देश्यों के लिए सुरक्षित नहीं माना जाता है।

erlang: md5_final (संदर्भ) -> डाइजेस्ट

प्रकार

MD5 के अद्यतन को समाप्त करता है Context और गणना किए गए MD5 संदेश को वापस लौटाता है।

erlang: md5_init () -> संदर्भ

प्रकार

एक एमडी 5 संदर्भ बनाता है, जिसका उपयोग निम्नलिखित कॉल में किया जाना है md5_update/2

erlang: md5_update (संदर्भ, डेटा) -> NewContext

प्रकार

एमडी 5 Context को अपडेट करें Data और रिटर्न करें NewContext

erlang: मेमोरी () -> [{प्रकार, आकार}]

प्रकार

Erlang एमुलेटर द्वारा गतिशील रूप से आवंटित मेमोरी के बारे में जानकारी के साथ एक सूची देता है। प्रत्येक सूची तत्व एक टपल है {Type, Size} । पहला तत्व Type स्मृति प्रकार का वर्णन करने वाला एक परमाणु है। दूसरा तत्व Size बाइट्स में मेमोरी का आकार है।

मेमोरी प्रकार:

total

वर्तमान में आवंटित स्मृति की कुल राशि। इस के लिए स्मृति आकार की राशि के रूप में एक ही है processes और system

processes

मेमोरी की कुल मात्रा वर्तमान में एरलंग प्रक्रियाओं के लिए आवंटित की गई है।

processes_used

वर्तमान में एरलंग प्रक्रियाओं द्वारा उपयोग की जाने वाली स्मृति की कुल मात्रा। यह स्मृति के रूप में प्रस्तुत स्मृति का हिस्सा है processes

system

स्मृति की कुल मात्रा वर्तमान में एमुलेटर के लिए आवंटित की गई है जो सीधे किसी भी एरलंग प्रक्रिया से संबंधित नहीं है। के रूप processes में प्रस्तुत स्मृति इस स्मृति में शामिल नहीं है। instrument(3) क्या इस प्रकार का हिस्सा है स्मृति का अधिक विस्तृत विखंडन प्राप्त करने के लिए इस्तेमाल किया जा सकता है।

atom

स्मृति की कुल मात्रा वर्तमान में परमाणुओं के लिए आवंटित की गई है। यह मेमोरी मेमोरी के रूप में प्रस्तुत मेमोरी का हिस्सा है system

atom_used

स्मृति की कुल मात्रा वर्तमान में परमाणुओं के लिए उपयोग की जाती है। यह मेमोरी मेमोरी के रूप में प्रस्तुत मेमोरी का हिस्सा है atom

binary

स्मृति की कुल मात्रा वर्तमान में बायनेरिज़ के लिए आवंटित की गई है। यह मेमोरी मेमोरी के रूप में प्रस्तुत मेमोरी का हिस्सा है system

code

वर्तमान में मेमोरी की कुल मात्रा Erlang कोड के लिए आवंटित की गई है। यह मेमोरी मेमोरी के रूप में प्रस्तुत मेमोरी का हिस्सा है system

ets

स्मृति की कुल मात्रा वर्तमान में ईटीएस तालिकाओं के लिए आवंटित की गई है। यह मेमोरी मेमोरी के रूप में प्रस्तुत मेमोरी का हिस्सा है system

low

केवल 64-बिट हाफवर्ड एमुलेटर पर। स्मृति की कुल मात्रा कम स्मृति क्षेत्रों में आवंटित की जाती है जो <4 जीबी तक सीमित है, हालांकि सिस्टम में अधिक मेमोरी हो सकती है।

भविष्य के आधे एमुलेटर के रिलीज में हटाया जा सकता है।

maximum

एमुलेटर शुरू होने के बाद से आवंटित अधिकतम स्मृति की मात्रा। यह ट्यूपल केवल तब मौजूद होता है जब एम्यूलेटर को इंस्ट्रूमेंटेशन के साथ चलाया जाता है।

इंस्ट्रूमेंटेशन के साथ एमुलेटर कैसे चलाएं, इसकी जानकारी के लिए देखें instrument(3) और / या erl(1)

ध्यान दें

system मूल्य पूरा नहीं हुआ है। कुछ आवंटित स्मृति जो इस मान का हिस्सा है, वह नहीं है।

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

जैसा कि total मूल्य का योग है processes और system , मूल्य के system लिए प्रसार में त्रुटि total

स्मृति की विभिन्न राशियाँ जिन्हें संक्षेप में एकत्र नहीं किया गया है, जो परिणाम में त्रुटि का परिचय देती हैं।

विभिन्न मूल्यों का एक दूसरे से निम्नलिखित संबंध है। बड़े अक्षर से शुरू होने वाले मान परिणाम का हिस्सा नहीं हैं।

total      = processes + system
processes  = processes_used + ProcessesNotUsed
system     = atom + binary + code + ets + OtherSystem
atom       = atom_used + AtomNotUsed
RealTotal  = processes + RealSystem
RealSystem = system + MissedSystem

लौटी सूची में अधिक टुपल्स को भविष्य के रिलीज में जोड़ा जा सकता है।

ध्यान दें

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

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

ध्यान दें

ईआरटीएस 5.6.4 के अनुसार, erlang:memory/0 आवश्यकता है कि सभी erts_alloc(3) आवंटन सक्षम हों (डिफ़ॉल्ट व्यवहार)।

विफलता: notsup यदि कोई erts_alloc(3) आवंटनकर्ता अक्षम किया गया है।

erlang: मेमोरी (प्रकार :: memory_type ()) -> पूर्णांक ()> = 0
erlang: मेमोरी (टाइपलिस्ट: [memory_type ()]) ->
[{memory_type (), पूर्णांक ()> = 0}]

प्रकार

प्रकार की मेमोरी के लिए आवंटित बाइट्स में मेमोरी का आकार लौटाता है Type । तर्क को memory_type() परमाणुओं की एक सूची के रूप में भी निर्दिष्ट किया जा सकता है , जिस स्थिति में {memory_type(), Size :: integer >= 0} ट्यूपल्स की एक समान सूची वापस आ जाती है।

ध्यान दें

ईआरटीएस 5.6.4 के अनुसार, erlang:memory/1 आवश्यकता है कि सभी erts_alloc(3) आवंटन सक्षम हों (डिफ़ॉल्ट व्यवहार)।

विफलताएं:

badarg
यदि Type विवरण में सूचीबद्ध स्मृति प्रकारों में से एक नहीं है erlang:memory/0
badarg
यदि के maximum रूप में पारित किया है Type और एम्यूलेटर साधन मोड में नहीं चलाया जाता है।
notsup
यदि कोई erts_alloc(3) आवंटनकर्ता अक्षम कर दिया गया है।

यह भी देखें erlang:memory/0

न्यूनतम (टर्म 1, टर्म 2) -> न्यूनतम

प्रकार

का सबसे छोटा Term1 और लौटाता है Term2 । यदि शब्द समान हैं, Term1 तो लौटा दिया जाता है।

मॉड्यूल_लोड (मॉड्यूल) -> बूलियन ()

प्रकार

रिटर्न true अगर मॉड्यूल Module लोड किया जाता है, नहीं तो false । यह मॉड्यूल को लोड करने का प्रयास नहीं करता है।

चेतावनी

यह BIF कोड सर्वर के लिए अभिप्रेत है (देखें code(3) ) और अन्यत्र उपयोग नहीं किया जाना है।

मॉनिटर (प्रकार :: प्रक्रिया, आइटम :: मॉनीटर_प्रोसेसर_फायर ()) ->
मॉनीटर रीफ
मॉनिटर (प्रकार :: पोर्ट, आइटम :: मॉनीटर_पोर्ट_ आईडिफायर ()) ->
मॉनिटररफ
मॉनिटर (टाइप करें :: time_offset, आइटम :: clock_service) -> मॉनिटररफ

प्रकार

Type द्वारा पहचानी गई इकाई के लिए एक प्रकार का मॉनिटर अनुरोध भेजता है Item । यदि मॉनिटर की गई इकाई मौजूद नहीं है या यह मॉनिटर की गई स्थिति को बदल देती है, तो कॉल करने वाले monitor/2 को निम्न प्रारूप पर एक संदेश द्वारा सूचित किया जाता है:

{Tag, MonitorRef, Type, Object, Info}
ध्यान दें

मॉनिटर अनुरोध एक अतुल्यकालिक संकेत है। यानी सिग्नल को अपने गंतव्य तक पहुंचने में समय लगता है।

Type : निम्नलिखित परमाणुओं में से एक हो सकता है process , port या time_offset

एक process या port मॉनिटर को केवल एक बार ट्रिगर किया जाता है, उसके बाद इसे मॉनिटरिंग प्रक्रिया और मॉनिटर की गई इकाई दोनों से हटा दिया जाता है। मॉनिटर की प्रक्रिया या पोर्ट समाप्त होने पर मॉनिटर्स निकाल दिए जाते हैं, निर्माण के समय मौजूद नहीं होता है, या यदि इसका कनेक्शन खो जाता है। यदि इसका कनेक्शन खो गया है, तो हम नहीं जानते कि क्या यह अभी भी मौजूद है। कहा जाने पर निगरानी भी बंद कर दी जाती demonitor(MonitorRef) है।

एक process या port नाम से नजर रखने के निराकरण RegisteredName के लिए pid() या port() पर नजर रखने के इन्स्टेन्शियशन के पल में केवल एक बार, नाम पंजीकरण करने के लिए बाद में परिवर्तन मौजूदा मॉनिटर को प्रभावित नहीं करेगा।

जब process या port मॉनिटर को ट्रिगर किया जाता है, तो एक 'DOWN' संदेश भेजा जाता है जिसमें निम्न पैटर्न होता है:

{'DOWN', MonitorRef, Type, Object, Info}

मॉनिटर संदेश में MonitorRef और Type पहले के रूप में वर्णित हैं, और:

Object

निगरानी इकाई, जिसने घटना को ट्रिगर किया। किसी स्थानीय प्रक्रिया या पोर्ट की निगरानी करते समय, Object उसके बराबर होगा pid() या port() उस पर नजर रखी जा रही थी। नाम से प्रक्रिया या पोर्ट की निगरानी करते समय, Object प्रारूप होगा {RegisteredName, Node} जहां RegisteredName वह नाम है जिसे monitor/2 कॉल के साथ उपयोग किया गया है और Node स्थानीय या दूरस्थ नोड नाम है (नाम से मॉनिटर किए गए पोर्ट के लिए, Node हमेशा स्थानीय नोड नाम होता है)।

Info

या तो प्रक्रिया का निकास कारण, noproc (प्रक्रिया या पोर्ट मॉनिटर निर्माण के समय मौजूद नहीं था), या noconnection (नोड से कोई संबंध नहीं है जहां मॉनिटर की गई प्रक्रिया रहती है)।

मॉनिटरिंग ए process

वर्तमान प्रक्रिया और इसके द्वारा पहचानी जाने वाली एक अन्य प्रक्रिया के बीच निगरानी रखता है Item , जो एक pid() (स्थानीय या दूरस्थ), एक पंजीकृत प्रक्रिया के लिए एक परमाणु RegisteredName या टपल हो {RegisteredName, Node} सकता है, जो अन्यत्र स्थित है।

ध्यान दें

ERTS 10.0 (OTP 21.0) से पहले, एक प्रक्रिया की निगरानी करना विफल हो सकता है badarg अगर निगरानी प्रक्रिया एक आदिम नोड (जैसे erl_interface या jinterface) पर रहती है, जहां दूरस्थ प्रक्रिया निगरानी लागू नहीं होती है।

अब, monitor इसके बजाय इस तरह की कॉल सफल होगी और एक मॉनिटर बनाया जाएगा। लेकिन मॉनिटर केवल कनेक्शन की निगरानी करेगा। यही है, एक {'DOWN', _, process, _, noconnection} एकमात्र संदेश है जो प्राप्त हो सकता है, क्योंकि आदिम नोड के पास निगरानी प्रक्रिया की स्थिति की रिपोर्ट करने का कोई तरीका नहीं है।

मॉनिटरिंग ए port

वर्तमान प्रक्रिया और इसके द्वारा पहचाने जाने वाले पोर्ट के बीच मॉनिटर बनाता है Item , जो इस नोड पर स्थित, पंजीकृत पोर्ट के लिए एक port() (केवल स्थानीय), परमाणु RegisteredName या ट्यूपल हो सकता {RegisteredName, Node} है। ध्यान दें, दूरस्थ पोर्ट की निगरानी करने के प्रयास के परिणामस्वरूप होगा badarg

मॉनिटरिंग ए time_offset

मॉनिटर और के time offset बीच में परिवर्तन होता है । एक मान्य परमाणु के साथ संयोजन में मौजूद है । ध्यान दें कि परमाणु है नहीं एक प्रक्रिया का पंजीकृत नाम। इस मामले में यह वर्तमान रनटाइम सिस्टम उदाहरण में रनटाइम सिस्टम आंतरिक घड़ी सेवा के पहचानकर्ता के रूप में कार्य करता है। Erlang monotonic time Erlang system time Item time_offset Type clock_service clock_service

जब समय में परिवर्तन किया जाता है तो मॉनिटर चालू हो जाता है। यह या तो यदि ऑफ़सेट मान को बदल दिया जाता है, या यदि ऑफ़सेट का उपयोग किए finalization of the time offset जाने के दौरान प्रारंभिक से अंतिम में बदल single time warp mode जाता है। जब प्रारंभिक से अंतिम समय तक ऑफसेट में बदलाव किया जाता है, तो मॉनिटर को एक बार ट्रिगर किया जाता है, भले ही उस समय ऑफसेट मान को बदल दिया गया हो या नहीं।

यदि रनटाइम सिस्टम चालू है multi time warp mode , तो रनटाइम सिस्टम पता लगाता है कि कब OS system time बदल गया है। रनटाइम सिस्टम, हालांकि, इसका पता नहीं चलता है जब ऐसा होता है। समय ऑफसेट की जांच करने वाला एक कार्य एक मिनट में कम से कम एक बार निष्पादित करने के लिए निर्धारित है, इसलिए सामान्य ऑपरेशन के तहत एक मिनट के भीतर इसका पता लगाया जाना है, लेकिन भारी भार के दौरान इसमें अधिक समय लग सकता है।

ट्रिगर के चालू होने के बाद मॉनिटर स्वचालित रूप से हटाया नहीं गया है। यही है, बार-बार होने वाले परिवर्तनों के बार-बार मॉनिटर को बार-बार ट्रिगर किया जाता है।

जब मॉनिटर को ट्रिगर किया जाता है तो एक 'CHANGE' संदेश निगरानी प्रक्रिया को भेजा जाता है। एक 'CHANGE' संदेश में निम्नलिखित पैटर्न है:

{'CHANGE', MonitorRef, Type, Item, NewTimeOffset}

जहां MonitorRef , Type और Item ऊपर वर्णित के रूप में ही हैं, और NewTimeOffset नए समय ऑफसेट है।

जब 'CHANGE' संदेश प्राप्त हो गया हो तो आपको कॉल करते समय पुराने समय की भरपाई न करने की गारंटी दी जाती है erlang:time_offset() । ध्यान दें कि आप संदेश erlang:time_offset() प्राप्त करने से पहले कॉल करते समय ऑफ़सेट के बदलाव का निरीक्षण कर सकते हैं 'CHANGE'

monitor/2 एक ही Item और / या के लिए कई कॉल करना Type कोई त्रुटि नहीं है; इसके परिणामस्वरूप कई स्वतंत्र निगरानी उदाहरण हैं।

मॉनिटर की कार्यक्षमता को बढ़ाया जाना अपेक्षित है। यही है, अन्य Type एस और Item एस को भविष्य के रिलीज में समर्थित होने की उम्मीद है।

ध्यान दें

अगर या जब monitor/2 के लिए बढ़ा दिया गया है, अन्य संभावित मान Tag , Object और Info पर नजर रखने के संदेश में पेश किया जाएगा।

मॉनिटर_नोड (नोड, ध्वज) -> सच

प्रकार

नोड की स्थिति की निगरानी करें Node । यदि Flag है true , तो निगरानी चालू है। यदि Flag है false , तो निगरानी बंद है।

monitor_node(Node, true) उसी के लिए कई कॉल करना Node कोई त्रुटि नहीं है; इसके परिणामस्वरूप कई स्वतंत्र निगरानी उदाहरण हैं।

यदि Node विफल रहता है या मौजूद नहीं है, तो संदेश {nodedown, Node} प्रक्रिया को दिया जाता है। यदि किसी प्रक्रिया ने दो कॉल किए monitor_node(Node, true) और Node समाप्त nodedown कर दिए हैं , तो दो संदेश प्रक्रिया को दिए जाते हैं। यदि कोई संबंध नहीं है Node , तो एक बनाने का प्रयास किया जाता है। यदि यह विफल रहता है, तो एक nodedown संदेश दिया जाता है।

छिपे हुए कनेक्शन के माध्यम से जुड़े नोड्स पर किसी अन्य नोड्स के रूप में नजर रखी जा सकती है।

विफलता: badarg यदि स्थानीय नोड जीवित नहीं है।

erlang: monitor_node (Node, Flag, Options) -> सच

प्रकार

monitor_node/2 इसके अलावा व्यवहार करता है कि यह एक अतिरिक्त विकल्प को निर्दिष्ट करने की अनुमति देता है, अर्थात् allow_passive_connect । यह विकल्प बीआईएफ को निगरानी नेटवर्क के लिए सामान्य नेटवर्क कनेक्शन टाइम-आउट की प्रतीक्षा करने की अनुमति देता है, भले ही वह इस नोड से सक्रिय रूप से जुड़ा न हो (यानी यह अवरुद्ध है)। वह राज्य जहां यह उपयोगी हो सकता है, केवल कर्नेल विकल्प का उपयोग करके प्राप्त किया जा सकता है dist_auto_connect once । यदि उस विकल्प का उपयोग नहीं किया जाता है, तो विकल्प allow_passive_connect का कोई प्रभाव नहीं पड़ता है।

ध्यान दें

विकल्प allow_passive_connect का उपयोग आंतरिक रूप से किया जाता है और शायद ही कभी उन अनुप्रयोगों में आवश्यक होता है जहां नेटवर्क टोपोलॉजी और प्रभाव में कर्नेल विकल्प पहले से ज्ञात हैं।

विफलता: badarg यदि स्थानीय नोड जीवित नहीं है या विकल्प सूची विकृत है।

erlang: monotonic_time () -> पूर्णांक ()

में करंट लौटाता Erlang monotonic time है native time_unit() । यह समय में कुछ अनिर्दिष्ट बिंदु के बाद से एक नीरस रूप से बढ़ता समय है।

ध्यान दें

यह एक monotonically increasing समय है, लेकिन एक समय नहीं है strictly monotonically increasing । यही है, लगातार कॉल erlang:monotonic_time/0 एक ही परिणाम का उत्पादन कर सकते हैं।

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

एरलैंग: मोनोटोनिक_टाइम (यूनिट) -> पूर्णांक ()

प्रकार

लौटे वर्तमान को तर्क के रूप Erlang monotonic time में परिवर्तित कर देता Unit है।

कॉलिंग के रूप erlang:convert_time_unit/3 ( erlang:monotonic_time() , native, Unit) में भी, हालांकि आमतौर पर इस्तेमाल किया के लिए अनुकूलित Unit

erlang: nif_error (कारण) -> no_return ()

प्रकार

बिल्कुल काम करता है error/1 , लेकिन डायलेज़र को लगता है कि यह BIF एक मनमाना शब्द लौटाएगा। जब NIF लाइब्रेरी लोड न हो, तो अपवाद उत्पन्न करने के लिए NIF के लिए स्टब फ़ंक्शन में उपयोग किया जाता है, तो Dialyzer गलत अर्थ उत्पन्न नहीं करता है।

erlang: nif_error (कारण, आर्ग्स) -> no_return ()

प्रकार

बिल्कुल काम करता है error/2 , लेकिन डायलेज़र को लगता है कि यह BIF एक मनमाना शब्द लौटाएगा। जब NIF लाइब्रेरी लोड न हो, तो अपवाद उत्पन्न करने के लिए NIF के लिए स्टब फ़ंक्शन में उपयोग किया जाता है, तो Dialyzer गलत अर्थ उत्पन्न नहीं करता है।

नोड () -> नोड

प्रकार

स्थानीय नोड का नाम देता है। यदि नोड जीवित नहीं है, [email protected] तो इसके बजाय वापस कर दिया जाता है।

गार्ड परीक्षण में अनुमति है।

नोड (Arg) -> नोड

प्रकार

उस नोड को लौटाता है जहां से Arg उत्पन्न होता है। Arg एक प्रक्रिया पहचानकर्ता, एक संदर्भ या एक बंदरगाह हो सकता है। यदि स्थानीय नोड जीवित नहीं है, [email protected] तो वापस कर दिया जाता है।

गार्ड परीक्षण में अनुमति है।

नोड्स () -> नोड्स

प्रकार

स्थानीय नोड को छोड़कर सिस्टम में सभी दृश्यमान नोड्स की सूची लौटाता है। के रूप में ही nodes(visible)

नोड्स (Arg) -> नोड्स

प्रकार

निर्दिष्ट तर्क के अनुसार नोड्स की सूची लौटाता है। लौटाया हुआ परिणाम, जब तर्क एक सूची है, तो सूची तत्वों के विघटन (ओं) को संतुष्ट करने वाले नोड्स की सूची है।

NodeType रों:

visible

सामान्य कनेक्शन के माध्यम से इस नोड से जुड़े नोड्स।

hidden

छिपे हुए कनेक्शन के माध्यम से इस नोड से जुड़े नोड्स।

connected

इस नोड से जुड़े सभी नोड्स।

this

यह नोड।

known

नोड्स जो इस नोड के लिए जाने जाते हैं। यही है, इस नोड पर स्थित प्रक्रिया पहचानकर्ताओं, पोर्ट पहचानकर्ताओं और संदर्भों द्वारा संदर्भित नोड्स और नोड्स जुड़े हुए हैं। ज्ञात नोड्स का सेट कचरा एकत्र किया जाता है। ध्यान दें कि इस कचरा संग्रहण में देरी हो सकती है। अधिक जानकारी के लिए, देखें erlang:system_info(delayed_node_table_gc)

कुछ समानताओं: [node()] = nodes(this) , nodes(connected) = nodes([visible, hidden]) , और nodes() = nodes(visible)

अब () -> टाइमस्टैम्प

प्रकार

चेतावनी

इस फ़ंक्शन को पदावनत किया जाता है। इसका प्रयोग न करें।

अधिक जानकारी के लिए, Time and Time Correction उपयोगकर्ता मार्गदर्शिका में अनुभाग देखें । विशेष रूप से, अनुभाग Dos and Dont's बताता है कि इसके बजाय क्या उपयोग करना है erlang:now/0

{MegaSecs, Secs, MicroSecs} अंतर्निहित ओएस द्वारा प्रदान किए जाने पर, टूपल , जो 00:00 GMT, 1 जनवरी, 1970 (शून्य घंटा) से बीता हुआ समय है। अन्यथा समय में किसी अन्य बिंदु को चुना जाता है। यह भी गारंटी है कि इस बीआईएफ के लिए निम्नलिखित कॉल लगातार बढ़ते मूल्यों को वापस करते हैं। इसलिए, erlang:now/0 अद्वितीय समय स्टैम्प उत्पन्न करने के लिए से वापसी मान का उपयोग किया जा सकता है। यदि इसे तेज मशीन पर एक तंग लूप में कहा जाता है, तो नोड का समय तिरछा हो सकता है।

केवल दिन के स्थानीय समय की जांच करने के लिए उपयोग किया जा सकता है यदि अंतर्निहित ओएस की समय-क्षेत्र की जानकारी ठीक से कॉन्फ़िगर की गई है।

ओपन_पोर्ट (पोर्टनेम, पोर्टसेटिंग) -> पोर्ट ()

प्रकार

नए Erlang पोर्ट को खोलने के परिणामस्वरूप एक पोर्ट पहचानकर्ता देता है। एक पोर्ट को बाहरी एरलंग प्रक्रिया के रूप में देखा जा सकता है।

निष्पादन के नाम के साथ-साथ बहस में specifed cd , env , args , और arg0 यूनिकोड फ़ाइल नाम अनुवाद के अधीन हैं, तो प्रणाली यूनिकोड फ़ाइल नाम मोड में चल रहा है। अनुवाद से या बल से बचने के लिए, उदाहरण के लिए, UTF-8, निष्पादन योग्य और / या तर्क को सही एन्कोडिंग में बाइनरी के रूप में आपूर्ति करता है। विवरण के लिए, मॉड्यूल file(3) , file:native_name_encoding/0 कर्नेल में फ़ंक्शन और Using Unicode in Erlang उपयोगकर्ता की मार्गदर्शिका देखें।

ध्यान दें

नाम में अक्षर (यदि एक सूची के रूप में निर्दिष्ट किया गया है) केवल 255 हो सकते हैं यदि यूनिकोड फ़ाइल नाम ट्रांसलेशन मोड में Erlang वर्चुअल मशीन शुरू की गई है। अन्यथा निष्पादन योग्य का नाम आईएसओ लैटिन -1 वर्ण सेट तक सीमित है।

PortName रों:

{spawn, Command}

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

सोलारिस पर बाहरी कार्यक्रम शुरू करते समय, प्रदर्शन कारणों vfork से वरीयता के fork लिए सिस्टम कॉल का उपयोग किया जाता है , हालांकि इसका इतिहास कम मजबूत है। यदि उपयोग vfork करने में समस्याएं हैं , तो इसके बजाय ERL_NO_VFORK किसी भी मान के कारण पर्यावरण चर सेट करना fork

बाहरी कार्यक्रमों के लिए, PATH खोज की जाती है (या ओएस के आधार पर कार्यक्रमों को खोजने के लिए एक समकक्ष विधि का उपयोग किया जाता है)। यह कुछ प्लेटफार्मों पर शेल को लागू करने के द्वारा किया जाता है। कमांड के पहले अंतरिक्ष-पृथक टोकन को निष्पादन योग्य (या ड्राइवर) के नाम के रूप में माना जाता है। यह (अन्य चीजों के बीच) इस विकल्प को फ़ाइल नाम या निर्देशिका नामों में रिक्त स्थान के साथ प्रोग्राम चलाने के लिए अनुपयुक्त बनाता है। यदि निष्पादन योग्य फ़ाइलनामों में रिक्त स्थान वांछित हैं, तो {spawn_executable, Command} इसके बजाय उपयोग करें ।

{spawn_driver, Command}

काम करता है {spawn, Command} , लेकिन लोड ड्राइवर का नाम होने के लिए कमांड के पहले (अंतरिक्ष-पृथक) टोकन की मांग करता है। यदि उस नाम का कोई ड्राइवर लोड नहीं है, तो एक badarg त्रुटि उठाई जाती है।

{spawn_executable, FileName}

की तरह काम करता है {spawn, FileName} , लेकिन केवल बाहरी निष्पादन योग्य चलाता है। FileName इसके पूरे में किसी भी रिक्त स्थान सहित निष्पादन योग्य के नाम के रूप में उपयोग किया जाता है। यदि तर्कों को पारित किया जाना है, PortSettings args और arg0 उपयोग किया जा सकता है।

शेल को आमतौर पर प्रोग्राम शुरू करने के लिए आमंत्रित नहीं किया जाता है, इसे सीधे निष्पादित किया जाता है। PATH (या समतुल्य) नहीं खोजा गया है। PATH निष्पादित करने के लिए एक कार्यक्रम खोजने के लिए, का उपयोग करें os:find_executable/1

केवल यदि कोई शेल स्क्रिप्ट या .bat फ़ाइल निष्पादित की जाती है, तो उपयुक्त कमांड दुभाषिया को अंतर्निहित रूप से लागू किया जाता है, लेकिन अभी भी कोई कमांड-तर्क विस्तार या अंतर्निहित PATH खोज नहीं है।

यदि FileName नहीं चलाया जा सकता है, तो POSIX त्रुटि कोड को कारण के रूप में एक त्रुटि अपवाद उठाया जाता है। त्रुटि का कारण ओएस के बीच भिन्न हो सकता है। आमतौर पर त्रुटि enoent तब उठाई जाती है जब एक प्रोग्राम चलाने का प्रयास किया जाता है जो कि नहीं पाया जाता है और eacces तब उठाया जाता है जब निर्दिष्ट फ़ाइल निष्पादन योग्य नहीं होती है।

{fd, In, Out}

Erlang द्वारा उपयोग की गई किसी भी वर्तमान में खोली गई फ़ाइल डिस्क्रिप्टर तक पहुँचने के लिए एक Erlang प्रक्रिया की अनुमति देता है। फ़ाइल डिस्क्रिप्टर In का उपयोग मानक इनपुट के लिए, और Out मानक आउटपुट के लिए फ़ाइल डिस्क्रिप्टर के लिए किया जा सकता है । इसका उपयोग केवल Erlang OS ( shell और user ) में विभिन्न सर्वरों के लिए किया जाता है । इसलिए, इसका उपयोग सीमित है।

PortSettings पोर्ट के लिए सेटिंग्स की एक सूची है। मान्य सेटिंग्स निम्नानुसार हैं:

{packet, N}

संदेश उनकी लंबाई से पहले होते हैं, N बाइट्स में भेजे जाते हैं , सबसे महत्वपूर्ण बाइट के साथ। मान्य मान N 1, 2 और 4 हैं।

stream

पैकेट लंबाई के बिना आउटपुट संदेश भेजे जाते हैं। एक उपयोगकर्ता-परिभाषित प्रोटोकॉल का उपयोग एर्लांग प्रक्रिया और बाहरी वस्तु के बीच होना चाहिए।

{line, L}

संदेश प्रति पंक्ति के आधार पर वितरित किए जाते हैं। प्रत्येक लाइन (ओएस-निर्भर न्यूलाइन अनुक्रम द्वारा सीमांकित) एक संदेश में वितरित की जाती है। संदेश डेटा स्वरूप है {Flag, Line} जहां, Flag है eol या noeol , और Line वितरित (newline अनुक्रम के बिना) डाटा नहीं है।

L बाइट्स में अधिकतम लाइन की लंबाई निर्दिष्ट करता है। इससे अधिक लंबी लाइनें एक से अधिक संदेशों में वितरित की जाती हैं, सभी के लिए Flag सेट noeol लेकिन अंतिम संदेश। यदि फ़ाइल का अंत किसी नई पंक्ति के तुरंत बाद कहीं और मिलता है, तो अंतिम पंक्ति Flag सेट के साथ भी दी जाती है noeol । अन्यथा लाइनों को Flag सेट के साथ वितरित किया जाता है eol

{packet, N} और {line, L} सेटिंग्स परस्पर अनन्य हैं।

{cd, Dir}

के लिए ही मान्य है {spawn, Command} और {spawn_executable, FileName} । बाहरी कार्यक्रम Dir इसकी कार्यशील निर्देशिका के रूप में उपयोग करना शुरू कर देता है । Dir एक तार होना चाहिए।

{env, Env}

प्रकार:
Name = os:env_var_name()
Val = os:env_var_value() | false
Env = [{Name, Val}]

केवल {spawn, Command} , और के लिए मान्य है {spawn_executable, FileName} । शुरू की प्रक्रिया के वातावरण में पर्यावरण विनिर्देशों का उपयोग कर बढ़ाया जाता है Env

Env ट्यूपल्स की एक सूची होना चाहिए {Name, Val} , जहां Name एक पर्यावरण चर का नाम है, और Val यह वह मूल्य है जो स्पॉन्स्ड पोर्ट प्रक्रिया में है। दोनों Name और Val तार होना चाहिए। एक अपवाद Val परमाणु के साथ false (सादृश्य में) हो रहा है os:getenv/1 , जो पर्यावरण चर को हटा देता है।

एन्कोडिंग आवश्यकताओं के बारे में जानकारी के लिए, के प्रकारों के दस्तावेज़ीकरण देखें Name और Val

{args, [ string() | binary() ]}

केवल {spawn_executable, FileName} निष्पादन योग्य के लिए तर्क के लिए मान्य और निर्दिष्ट करता है। प्रत्येक तर्क को एक अलग स्ट्रिंग के रूप में निर्दिष्ट किया गया है और (यूनिक्स पर) अंततः तर्क वेक्टर में एक तत्व के रूप में समाप्त होता है। अन्य प्लेटफार्मों पर, एक समान व्यवहार की नकल की जाती है।

निष्पादन योग्य को दिए जाने से पहले शेल द्वारा तर्कों का विस्तार नहीं किया जाता है। सबसे विशेष रूप से इसका मतलब है कि फ़ाइल वाइल्डकार्ड विस्तार नहीं होता है। तर्कों के लिए वाइल्डकार्ड का विस्तार करने के लिए, उपयोग करें filelib:wildcard/1 । ध्यान दें कि भले ही कार्यक्रम एक यूनिक्स शेल स्क्रिप्ट है, जिसका अर्थ है कि शेल अंततः आमंत्रित किया गया है, वाइल्डकार्ड विस्तार नहीं होता है, और स्क्रिप्ट अछूता तर्कों के साथ प्रदान की जाती है। विंडोज पर, वाइल्डकार्ड विस्तार हमेशा कार्यक्रम के लिए ही होता है, इसलिए यह कोई मुद्दा नहीं है।

निष्पादन योग्य नाम (जिसे भी जाना जाता है argv[0] ) को इस सूची में निर्दिष्ट नहीं किया जाना है। उचित निष्पादन योग्य नाम स्वचालित रूप से उपयोग किया जाता है argv[0] , जहां लागू हो।

यदि आप स्पष्ट रूप से तर्क वेक्टर में प्रोग्राम का नाम सेट करना चाहते हैं, तो विकल्प arg0 का उपयोग किया जा सकता है।

{arg0, string() | binary()}

केवल {spawn_executable, FileName} निष्पादन योग्य होने पर प्रोग्राम नाम तर्क के लिए केवल मान्य और स्पष्ट रूप से निर्दिष्ट करता है। यह कुछ परिस्थितियों में, कुछ ओएस पर, वांछनीय हो सकता है। यह कैसे प्रतिक्रिया करता है कार्यक्रम अत्यधिक प्रणाली पर निर्भर है और कोई विशेष प्रभाव की गारंटी नहीं है।

exit_status

केवल के लिए मान्य है {spawn, Command} , जहां Command एक बाहरी कार्यक्रम को संदर्भित करता है, और के लिए {spawn_executable, FileName}

जब पोर्ट से जुड़ी बाहरी प्रक्रिया बाहर निकल जाती है, तो फॉर्म {Port,{exit_status,Status}} का एक संदेश कनेक्टेड प्रक्रिया को भेज दिया जाता है, जहां Status बाहरी प्रक्रिया की निकास स्थिति होती है। यदि कार्यक्रम यूनिक्स पर गर्भपात करता है, तो उसी सम्मेलन का उपयोग किया जाता है जैसे कि गोले करते हैं (अर्थात, 128 + सिग्नल)।

विकल्प तो eof भी निर्दिष्ट किया जाता है, संदेशों eof और exit_status एक अनिर्दिष्ट क्रम में दिखाई देते हैं।

यदि पोर्ट प्रोग्राम stdout बाहर निकलने के बिना बंद हो जाता है , तो विकल्प exit_status काम नहीं करता है।

use_stdio

के लिए ही मान्य है {spawn, Command} और {spawn_executable, FileName} । यह Erlang के साथ संचार के लिए स्पॉन्ड (यूनिक्स) प्रक्रिया के मानक इनपुट और आउटपुट (फ़ाइल डिस्क्रिप्टर 0 और 1) को अनुमति देता है।

nouse_stdio

के विपरीत है use_stdio । यह Erlang के साथ संचार के लिए फ़ाइल डिस्क्रिप्टर 3 और 4 का उपयोग करता है।

stderr_to_stdout

बाहरी कार्यक्रमों के लिए बंदरगाहों को प्रभावित करता है। निष्पादित प्रोग्राम अपनी मानक त्रुटि फ़ाइल को अपनी मानक आउटपुट फ़ाइल पर पुनर्निर्देशित करता है। stderr_to_stdout और nouse_stdio परस्पर अनन्य हैं।

overlapped_io

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

in

पोर्ट का उपयोग केवल इनपुट के लिए किया जा सकता है।

out

पोर्ट का उपयोग केवल आउटपुट के लिए किया जा सकता है।

binary

पोर्ट से सभी I / O बाइनरी डेटा ऑब्जेक्ट्स हैं जो बाइट्स की सूचियों के विपरीत हैं।

eof

फ़ाइल के अंत में पोर्ट बंद नहीं होता है और बाहर निकलने का संकेत नहीं देता है। इसके बजाय, यह खुला रहता है और {Port, eof} पोर्ट को पकड़े जाने की प्रक्रिया के लिए एक संदेश भेजा जाता है।

hide

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

{parallelism, Boolean}

पोर्ट समानता के लिए शेड्यूलर संकेत सेट करता है। अगर true , वर्चुअल मशीन शेड्यूल पोर्ट कार्यों के लिए सेट है; ऐसा करते समय, यह प्रणाली में समानता में सुधार करता है। यदि सेट किया जाता है false , तो वर्चुअल मशीन समानांतर कार्यों की कीमत पर विलंबता में सुधार करते हुए, तुरंत पोर्ट कार्य करने की कोशिश करती है। डिफॉल्ट को कमांड-लाइन तर्क पास करके सिस्टम स्टार्टअप पर सेट किया जा सकता +spp है erl(1)

डिफ़ॉल्ट stream सभी पोर्ट प्रकारों के लिए और use_stdio स्पॉन पोर्ट्स के लिए है।

विफलता: यदि पोर्ट खोला नहीं जा सकता, बाहर निकलें कारण है badarg , system_limit या POSIX त्रुटि कोड है कि सबसे निकट त्रुटि का वर्णन करता है, या einval अगर कोई POSIX कोड उचित है:

badarg
खराब इनपुट तर्क open_port
system_limit
Erlang एमुलेटर में सभी उपलब्ध पोर्ट उपयोग में हैं।
enomem
पोर्ट बनाने के लिए पर्याप्त मेमोरी नहीं है।
eagain
कोई और उपलब्ध OS प्रक्रिया नहीं।
enametoolong
बहुत लंबी बाहरी कमान।
emfile
कोई और अधिक उपलब्ध फ़ाइल डिस्क्रिप्टर (OS प्रक्रिया के लिए जो Erlang एमुलेटर चलता है)।
enfile
पूर्ण फ़ाइल तालिका (संपूर्ण ओएस के लिए)।
eacces
Command निर्दिष्ट {spawn_executable, Command} एक निष्पादन योग्य फ़ाइल को इंगित नहीं करता है।
enoent
FileName निर्दिष्ट {spawn_executable, FileName} मौजूदा फ़ाइल को इंगित नहीं करता है।

के दौरान एक बंदरगाह के उपयोग का उपयोग कर खोला {spawn, Name} , {spawn_driver, Name} या {spawn_executable, Name} , त्रुटियों उत्पन्न होने वाली जब संदेश भेजने के लिए यह मालिक प्रक्रिया फार्म के संकेतों का उपयोग करने के लिए रिपोर्ट कर रहे हैं {'EXIT', Port, PosixCode} । के संभावित मूल्यों के लिए PosixCode , देखें file(3)

पोर्ट की अधिकतम संख्या जो एक ही समय में खुली हो सकती है, कमांड-लाइन फ्लैग +Q को पास करके कॉन्फ़िगर किया जा सकता है erl(1)

erlang: phash (टर्म, रेंज) -> हैश

प्रकार

रेंज = 1..2 ^ 32, हैश = 1.रेंज

पोर्टेबल हैश फ़ंक्शन जो मशीन आर्किटेक्चर और ईआरटीएस संस्करण (बीआईएफ को ईआरटीएस 4.9.1.1 में पेश किया गया था) की परवाह किए बिना एक ही एरलंग शब्द के लिए समान हैश देता है। फ़ंक्शन Term सीमा के भीतर हैश मान लौटाता है 1..Range । अधिकतम मूल्य Range 2 ^ 32 है।

erlang: phash2 (टर्म) -> हैश
erlang: phash2 (टर्म, रेंज) -> हैश

प्रकार

1..2 ^ 32

0..Range -1

पोर्टेबल हैश फ़ंक्शन जो मशीन वास्तुकला और ईआरटीएस संस्करण (बीआईएफ को ईआरटीएस 5.2 में पेश किया गया था) की परवाह किए बिना एक ही एरलंग शब्द के लिए समान हैश देता है। फ़ंक्शन Term सीमा के भीतर हैश मान लौटाता है 0..Range-1 । अधिकतम मूल्य Range 2 ^ 32 है। जब तर्क के बिना Range , 0..2 ^ 27-1 सीमा में एक मान लौटाया जाता है।

यह BIF हमेशा हैशिंग शब्दों के लिए उपयोग किया जाता है। यह छोटे पूर्णांक की तुलना में बेहतर वितरित करता है phash/2 , और यह बोली और बायनेरिज़ के लिए तेज़ है।

ध्यान दें कि सीमा 0..Range-1 , की सीमा से अलग है phash/2 , जो है 1..Range

pid_to_list (Pid) -> स्ट्रिंग ()

प्रकार

के पाठ प्रतिनिधित्व के अनुरूप एक स्ट्रिंग लौटाता है Pid

erlang: port_call (पोर्ट, ऑपरेशन, डेटा) -> टर्म ()

प्रकार

पोर्ट के लिए एक तुल्यकालिक कॉल करता है। पोर्ट ड्राइवर पर, का अर्थ Operation और Data निर्भर करता है। सभी पोर्ट ड्राइवर इस सुविधा का समर्थन नहीं करते हैं।

Port एक बंदरगाह पहचानकर्ता है, एक ड्राइवर का जिक्र है।

Operation एक पूर्णांक है, जो चालक को दिया जाता है।

Data कोई भी इरलंग शब्द है। यह डेटा बाइनरी टर्म फॉर्मेट में बदलकर पोर्ट पर भेजा जाता है।

ड्राइवर से एक शब्द वापस करता है। लौटाए गए डेटा का अर्थ भी पोर्ट ड्राइवर पर निर्भर करता है।

विफलताएं:

badarg
यदि Port एक खुले बंदरगाह का पहचानकर्ता नहीं है, या एक खुले बंदरगाह का पंजीकृत नाम है। यदि कॉलिंग प्रक्रिया को पहले बंद पोर्ट से जोड़ा गया था, तो पहचान की जाती है Port , पोर्ट से बाहर निकलने का संकेत इस badarg अपवाद के होने से पहले वितरित होने की गारंटी है।
badarg
यदि Operation 32-बिट पूर्णांक में फिट नहीं होता है।
badarg
यदि पोर्ट ड्राइवर सिंक्रोनस नियंत्रण संचालन का समर्थन नहीं करता है।
badarg
यदि पोर्ट ड्राइवर किसी भी कारण से निर्णय लेता है (शायद कुछ गलत है Operation या Data )।
port_close (पोर्ट) -> सच

प्रकार

एक खुला बंदरगाह बंद कर देता है। मोटे तौर पर Port ! {self(), close} त्रुटि व्यवहार (नीचे देखें) को छोड़कर, तुल्यकालिक होने के समान है, और यह कि पोर्ट के साथ उत्तर नहीं देता है {Port, closed} । कोई भी प्रक्रिया एक पोर्ट को बंद कर सकती है port_close/1 , न कि केवल पोर्ट मालिक (कनेक्टेड प्रोसेस) को। यदि कॉलिंग प्रक्रिया द्वारा पहचाने गए पोर्ट से जुड़ा हुआ है Port , तो port_close/1 रिटर्न से पहले पोर्ट से बाहर निकलने का संकेत दिया जाएगा ।

तुलना के लिए: Port ! {self(), close} केवल एक बंदरगाह या एक प्रक्रिया को संदर्भित नहीं करता है badarg तो विफल रहता Port है। अगर Port एक बंद बंदरगाह है, तो कुछ भी नहीं होता है। यदि Port एक खुला पोर्ट है और कॉलिंग प्रक्रिया पोर्ट मालिक है, तो पोर्ट {Port, closed} तब जवाब देता है जब सभी बफ़र्स को फ्लश किया गया हो और पोर्ट बंद हो गया हो। यदि कॉलिंग प्रक्रिया पोर्ट स्वामी नहीं है, तो पोर्ट स्वामी विफल रहता है badsig

ध्यान दें कि कोई भी प्रक्रिया किसी पोर्ट को बंद कर सकती है Port ! {PortOwner, close} जैसे कि वह खुद पोर्ट ओनर था, लेकिन रिप्लाई हमेशा पोर्ट ओनर के पास जाता है।

Erlang / OTP R16 से, Port ! {PortOwner, close} वास्तव में अतुल्यकालिक है। ध्यान दें कि इस ऑपरेशन को हमेशा एक अतुल्यकालिक ऑपरेशन के रूप में प्रलेखित किया गया है, जबकि अंतर्निहित कार्यान्वयन तुल्यकालिक है। port_close/1 हालांकि अभी भी पूरी तरह से अपनी त्रुटि व्यवहार के कारण तुल्यकालिक है।

असफलता: badarg यदि Port एक खुले बंदरगाह का पहचानकर्ता नहीं है, या एक खुले बंदरगाह का पंजीकृत नाम नहीं है। यदि कॉलिंग प्रक्रिया को पहले बंद पोर्ट से जोड़ा गया था, तो पहचान की जाती है Port , पोर्ट से बाहर निकलने का संकेत इस badarg अपवाद के होने से पहले वितरित होने की गारंटी है।

port_command (पोर्ट, डेटा) -> सच

प्रकार

एक पोर्ट के लिए डेटा भेजता है। Port ! {PortOwner, {command, Data}} त्रुटि व्यवहार को छोड़कर और समकालिक होने के अलावा (नीचे देखें)। कोई भी प्रक्रिया port_command/2 केवल पोर्ट के मालिक (कनेक्टेड प्रक्रिया) के साथ , पोर्ट को डेटा भेज सकती है ।

तुलना के लिए: Port ! {PortOwner, {command, Data}} केवल एक बंदरगाह या एक प्रक्रिया को संदर्भित नहीं करता है badarg तो विफल रहता Port है। यदि Port कोई बंद पोर्ट है, तो ध्वनि के बिना डेटा संदेश गायब हो जाता है। यदि Port खुला है और कॉलिंग प्रक्रिया पोर्ट स्वामी नहीं है, तो पोर्ट स्वामी विफल रहता है badsig badsig यदि Data कोई अमान्य I / O सूची है, तो पोर्ट स्वामी भी विफल रहता है।

ध्यान दें कि कोई भी प्रक्रिया पोर्ट का उपयोग करके भेज सकती है Port ! {PortOwner, {command, Data}} जैसे कि वह खुद पोर्ट मालिक थी।

यदि पोर्ट व्यस्त है, तो कॉलिंग प्रक्रिया तब तक निलंबित रहती है जब तक कि पोर्ट अधिक व्यस्त न हो।

Erlang / OTP R16 से, Port ! {PortOwner, {command, Data}} वास्तव में अतुल्यकालिक है। ध्यान दें कि इस ऑपरेशन को हमेशा एक अतुल्यकालिक ऑपरेशन के रूप में प्रलेखित किया गया है, जबकि अंतर्निहित कार्यान्वयन तुल्यकालिक है। port_command/2 हालांकि अभी भी पूरी तरह से अपनी त्रुटि व्यवहार के कारण तुल्यकालिक है।

विफलताएं:

badarg

यदि Port एक खुले बंदरगाह का पहचानकर्ता नहीं है, या एक खुले बंदरगाह का पंजीकृत नाम है। यदि कॉलिंग प्रक्रिया को पहले बंद पोर्ट से जोड़ा गया था, तो पहचान की जाती है Port , पोर्ट से बाहर निकलने का संकेत इस badarg अपवाद के होने से पहले वितरित होने की गारंटी है।

badarg

यदि Data एक अमान्य I / O सूची है।

port_command (पोर्ट, डेटा, ऑप्शनलिस्ट) -> बूलियन ()

प्रकार

एक पोर्ट के लिए डेटा भेजता है। port_command(Port, Data, []) बराबर होता है port_command(Port, Data)

यदि पोर्ट कमांड निरस्त है, false तो वापस कर दिया जाता है, अन्यथा true

यदि पोर्ट व्यस्त है, तो कॉलिंग प्रक्रिया तब तक निलंबित है जब तक कि पोर्ट अब व्यस्त नहीं है।

Option रों:

force
यदि पोर्ट व्यस्त है, तो कॉलिंग प्रक्रिया निलंबित नहीं है, इसके बजाय पोर्ट कमांड के माध्यम से मजबूर किया जाता है। notsup यदि पोर्ट का ड्राइवर इस का समर्थन नहीं करता है तो कॉल अपवाद के साथ विफल हो जाता है । अधिक जानकारी के लिए, चालक ध्वज देखें ![CDATA[ERL_DRV_FLAG_SOFT_BUSY]]
nosuspend
यदि पोर्ट व्यस्त है, तो इसके बजाय पोर्ट कमांड को निरस्त कर दिया जाता है और कॉलिंग प्रक्रिया को निलंबित कर दिया जाता है false
ध्यान दें

भविष्य के रिलीज़ में अधिक विकल्प जोड़े जा सकते हैं।

विफलताएं:

badarg
यदि Port एक खुले बंदरगाह का पहचानकर्ता नहीं है, या एक खुले बंदरगाह का पंजीकृत नाम है। यदि कॉलिंग प्रक्रिया को पहले बंद पोर्ट से जोड़ा गया था, तो पहचान की जाती है Port , पोर्ट से बाहर निकलने का संकेत इस badarg अपवाद के होने से पहले वितरित होने की गारंटी है।
badarg
यदि Data एक अमान्य I / O सूची है।
badarg
यदि OptionList एक अमान्य विकल्प सूची है।
notsup
यदि विकल्प force पारित कर दिया गया है, लेकिन पोर्ट का ड्राइवर व्यस्त पोर्ट के माध्यम से मजबूर करने की अनुमति नहीं देता है।
port_connect (पोर्ट, पीआईडी) -> सच

प्रकार

पोर्ट स्वामी (कनेक्टेड पोर्ट) को सेट करता है Pid । मोटे तौर पर Port ! {Owner, {connect, Pid}} निम्नलिखित को छोड़कर समान है :

  • त्रुटि व्यवहार अलग है, नीचे देखें।

  • पोर्ट के साथ उत्तर नहीं देता है {Port,connected}

  • port_connect/1 तुल्यकालिक है, नीचे देखें।

  • नया पोर्ट मालिक पोर्ट से जुड़ जाता है।

पुराना पोर्ट मालिक पोर्ट से जुड़ा रहता है और unlink(Port) अगर यह वांछित नहीं है तो कॉल करना चाहिए । कोई भी प्रक्रिया पोर्ट मालिक को किसी भी प्रक्रिया के साथ सेट कर सकती है port_connect/2

तुलना के लिए: Port ! {self(), {connect, Pid}} केवल एक बंदरगाह या एक प्रक्रिया को संदर्भित नहीं करता है badarg तो विफल रहता Port है। अगर Port एक बंद बंदरगाह है, तो कुछ भी नहीं होता है। यदि Port एक खुला बंदरगाह है और कॉलिंग प्रक्रिया पोर्ट स्वामी है, तो पोर्ट {Port, connected} पुराने पोर्ट स्वामी के साथ उत्तर देता है । ध्यान दें कि पुराना पोर्ट मालिक अभी भी पोर्ट से जुड़ा हुआ है, जबकि नया नहीं है। यदि Port एक खुला पोर्ट है और कॉलिंग प्रक्रिया पोर्ट स्वामी नहीं है, तो पोर्ट स्वामी विफल रहता है badsig badsig यदि Pid मौजूदा स्थानीय प्रक्रिया पहचानकर्ता नहीं है, तो पोर्ट स्वामी भी विफल रहता है।

ध्यान दें कि कोई भी प्रक्रिया पोर्ट मालिक को सेट कर सकती है Port ! {PortOwner, {connect, Pid}} जैसे कि वह स्वयं पोर्ट मालिक थी, लेकिन उत्तर हमेशा पोर्ट के मालिक को जाता है।

Erlang / OTP R16 से, Port ! {PortOwner, {connect, Pid}} वास्तव में अतुल्यकालिक है। ध्यान दें कि इस ऑपरेशन को हमेशा एक अतुल्यकालिक ऑपरेशन के रूप में प्रलेखित किया गया है, जबकि अंतर्निहित कार्यान्वयन तुल्यकालिक है। port_connect/2 हालांकि अभी भी पूरी तरह से अपनी त्रुटि व्यवहार के कारण तुल्यकालिक है।

विफलताएं:

badarg
यदि Port एक खुले बंदरगाह का पहचानकर्ता नहीं है, या एक खुले बंदरगाह का पंजीकृत नाम है। यदि कॉलिंग प्रक्रिया को पहले बंद पोर्ट से जोड़ा गया था, तो पहचान की जाती है Port , पोर्ट से बाहर निकलने का संकेत इस badarg अपवाद के होने से पहले वितरित होने की गारंटी है।
badarg
यदि द्वारा पहचानी गई Pid प्रक्रिया मौजूदा स्थानीय प्रक्रिया नहीं है।
port_control (पोर्ट, ऑपरेशन, डेटा) -> आयोडेटा () | बाइनरी ()

प्रकार

एक पोर्ट पर एक सिंक्रोनस कंट्रोल ऑपरेशन करता है। पोर्ट ड्राइवर पर, का अर्थ Operation और Data निर्भर करता है। सभी पोर्ट ड्राइवर इस नियंत्रण सुविधा का समर्थन नहीं करते हैं।

पोर्ट ड्राइवर के आधार पर, 0..255 या बाइनरी में पूर्णांकों की सूची देता है। लौटाए गए डेटा का अर्थ भी पोर्ट ड्राइवर पर निर्भर करता है।

विफलताएं:

badarg
यदि Port एक खुला बंदरगाह या एक खुले बंदरगाह का पंजीकृत नाम नहीं है।
badarg
यदि Operation 32-बिट पूर्णांक में फिट नहीं हो सकते।
badarg
यदि पोर्ट ड्राइवर सिंक्रोनस नियंत्रण संचालन का समर्थन नहीं करता है।
badarg
यदि पोर्ट ड्राइवर किसी भी कारण से निर्णय लेता है (शायद कुछ गलत है Operation या Data )।
erlang: port_info (पोर्ट) -> परिणाम

प्रकार

एक सूची देता है जिसमें टुपल्स के बारे में जानकारी होती है Port , या undefined यदि पोर्ट खुला नहीं है। टुपल्स का क्रम अपरिभाषित है, और सभी टुपल्स अनिवार्य नहीं हैं। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/1 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

परिणाम में निम्नलिखित Item s के बारे में जानकारी शामिल है :

  • registered_name (यदि पोर्ट में एक पंजीकृत नाम है)
  • id
  • connected
  • links
  • name
  • input
  • output

विभिन्न Item एस के बारे में अधिक जानकारी के लिए , देखें port_info/2

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: कनेक्टेड) ​​->
{कनेक्टेड, Pid} | अपरिभाषित

प्रकार

Pid पोर्ट से जुड़ी प्रक्रिया की प्रक्रिया पहचानकर्ता है।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: आईडी) -> {आईडी, इंडेक्स} | अपरिभाषित

प्रकार

Index बंदरगाह का आंतरिक सूचकांक है। इस इंडेक्स का उपयोग पोर्ट को अलग करने के लिए किया जा सकता है।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: इनपुट) ->
{इनपुट, बाइट्स} | अपरिभाषित

प्रकार

Bytes पोर्ट से पढ़ी जाने वाली बाइट्स की कुल संख्या है।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: लिंक) -> {लिंक्स, Pids} | अपरिभाषित

प्रकार

Pids उन प्रक्रियाओं के प्रक्रिया पहचानकर्ताओं की एक सूची है जो पोर्ट से जुड़ा हुआ है।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: लॉकिंग) ->
{लॉकिंग, लॉकिंग} | अपरिभाषित

प्रकार

Locking निम्नलिखित में से एक है:

  • port_level (पोर्ट-विशिष्ट लॉकिंग)
  • driver_level (ड्राइवर-विशिष्ट लॉकिंग)

ध्यान दें कि ये परिणाम अत्यधिक कार्यान्वयन-विशिष्ट हैं और भविष्य के रिलीज़ में बदल सकते हैं।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: मेमोरी) ->
{मेमोरी, बाइट्स} | अपरिभाषित

प्रकार

Bytes रनटाइम सिस्टम द्वारा इस पोर्ट के लिए आवंटित बाइट्स की कुल संख्या है। पोर्ट में ही ऐसी मेमोरी आवंटित की जा सकती है जो इसमें शामिल नहीं है Bytes

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: मॉनिटर) ->
{मॉनिटर, मॉनिटर्स} | अपरिभाषित

प्रकार

Monitors इस पोर्ट द्वारा मॉनिटर की गई प्रक्रियाओं का प्रतिनिधित्व करते हैं।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: मॉनिटर किए गए_बी) ->
{मॉनिटर किए गए_बाय , मॉनिटर किए गए} | अपरिभाषित

प्रकार

पल की सूची देता है जो उस समय दिए गए पोर्ट की निगरानी कर रहे हैं।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: नाम) -> {नाम, नाम} | अपरिभाषित

प्रकार

Name द्वारा निर्धारित कमांड नाम है open_port/2

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: os_pid) ->
{os_pid, OsPid} | अपरिभाषित

प्रकार

OsPid के साथ बनाई गई एक ओएस प्रक्रिया की प्रक्रिया पहचानकर्ता (या समकक्ष) है open_port/2 । यदि पोर्ट ओएस प्रक्रिया को जन्म देने का परिणाम नहीं है, तो मान है undefined

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: आउटपुट) ->
{आउटपुट, बाइट्स} | अपरिभाषित

प्रकार

Bytes उपयोग या port_command/2 , Erlang प्रक्रियाओं से बंदरगाह को लिखे गए बाइट्स की कुल संख्या है port_command/3 , या Port ! {Owner, {command, Data}

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: समानतावाद) ->
{समानांतरवाद, बुलियन} | अपरिभाषित

प्रकार

Boolean इस पोर्ट द्वारा उपयोग किए जाने वाले पोर्ट समानतावाद संकेत से मेल खाती है। अधिक जानकारी के लिए विकल्प दिखाई parallelism की open_port/2

erlang: port_info (पोर्ट, आइटम :: queue_size) ->
{queue_size, बाइट्स} | अपरिभाषित

प्रकार

Bytes ईआरटीएस चालक कतार कार्यान्वयन का उपयोग करके पोर्ट द्वारा पंक्तिबद्ध बाइट्स की कुल संख्या है।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

erlang: port_info (पोर्ट, आइटम :: पंजीकृत_नाम) ->
{ पंजीकृत_नाम, पंजीकृतनाम } |
[] |
अपरिभाषित

प्रकार

RegisteredName बंदरगाह का पंजीकृत नाम है। यदि पोर्ट का कोई पंजीकृत नाम नहीं है, [] तो वापस कर दिया जाता है।

यदि द्वारा पहचाना गया पोर्ट Port खुला नहीं है, undefined तो लौटा दिया जाता है। यदि पोर्ट बंद है और कॉलिंग प्रक्रिया पहले पोर्ट से जुड़ी हुई थी, तो पोर्ट से निकलने वाले सिग्नल को port_info/2 रिटर्न से पहले डिलीवर होने की गारंटी है undefined

विफलता: badarg यदि Port कोई स्थानीय पोर्ट पहचानकर्ता या परमाणु नहीं है।

port_to_list (पोर्ट) -> स्ट्रिंग ()

प्रकार

पोर्ट पहचानकर्ता के पाठ प्रतिनिधित्व के अनुरूप स्ट्रिंग देता है Port

erlang: पोर्ट्स () -> [पोर्ट ()]

स्थानीय नोड पर मौजूद सभी पोर्ट के लिए पोर्ट पहचानकर्ताओं की सूची लौटाता है।

ध्यान दें कि एक निकास बंदरगाह मौजूद है, लेकिन खुला नहीं है।

pre_loaded () -> [मॉड्यूल ()]

सिस्टम में पहले से लोड किए गए Erlang मॉड्यूल की सूची लौटाता है। जैसा कि कोड का सभी लोडिंग फाइल सिस्टम के माध्यम से किया जाता है, फाइल सिस्टम को पहले लोड किया जाना चाहिए। इसलिए, कम से कम मॉड्यूल init को पहले से लोड किया जाना चाहिए।

erlang: process_display (Pid, टाइप) -> सच

प्रकार

Pid मानक त्रुटि पर स्थानीय प्रक्रिया के बारे में जानकारी लिखता है । परमाणु के लिए केवल अनुमत मूल्य Type है backtrace , जो कॉल स्टैक की सामग्री को दिखाता है , जिसमें कॉल चेन के बारे में जानकारी शामिल है, जिसमें पहले फ़ंक्शन मुद्रित होता है। आउटपुट का प्रारूप आगे परिभाषित नहीं है।

process_flag (ध्वज :: trap_exit, Boolean) -> OldBoolean

प्रकार

जब trap_exit सेट किया जाता है true , तो एक प्रक्रिया में आने वाले सिग्नल बाहर निकलकर {'EXIT', From, Reason} संदेशों में बदल जाते हैं , जिन्हें साधारण संदेशों के रूप में प्राप्त किया जा सकता है। यदि trap_exit इसे सेट किया जाता है false , तो यह प्रक्रिया बाहर निकलती है अगर इसे इसके अलावा कोई निकास संकेत प्राप्त होता है normal और बाहर निकलने का संकेत इसकी जुड़ी प्रक्रियाओं के लिए प्रचारित किया जाता है। आवेदन प्रक्रियाएं आम तौर पर बाहर निकलने के लिए नहीं होती हैं।

झंडे का पुराना मूल्य लौटाता है।

यह भी देखें exit/2

process_flag (ध्वज :: error_handler, मॉड्यूल) -> OldModule

प्रकार

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

झंडे का पुराना मूल्य लौटाता है।

process_flag (ध्वज :: min_heap_size, MinHeapSize) -> OldMinHeapSize

प्रकार

कॉलिंग प्रक्रिया के लिए न्यूनतम हीप आकार बदलता है।

झंडे का पुराना मूल्य लौटाता है।

process_flag (ध्वज :: min_bin_vheap_size, MinBinVHeapSize) ->
OldMinBinVHeapSize

प्रकार

कॉलिंग प्रक्रिया के लिए न्यूनतम बाइनरी वर्चुअल हीप आकार बदलता है।

झंडे का पुराना मूल्य लौटाता है।

process_flag (ध्वज :: max_heap_size, MaxHeapSize) -> OldMaxHeapSize

प्रकार

यह ध्वज कॉलिंग प्रक्रिया के लिए अधिकतम ढेर आकार निर्धारित करता है। यदि MaxHeapSize एक पूर्णांक है, के लिए प्रणाली मूलभूत मूल्यों kill और error_logger उपयोग किया जाता है।

size

प्रक्रिया के शब्दों में अधिकतम आकार। यदि शून्य पर सेट किया जाता है, तो हीप आकार सीमा अक्षम है। badarg मान से छोटा होने पर फेंक दिया जाता है min_heap_size । आकार की जांच केवल तब की जाती है जब कचरा संग्रह शुरू हो जाता है।

size प्रक्रिया का पूरा ढेर है जब कचरा संग्रह शुरू हो जाता है। इसमें सभी पीढ़ीगत ढेर, प्रक्रिया स्टैक, कोई भी messages that are considered to be part of the heap , और कोई भी अतिरिक्त मेमोरी शामिल है जिसे संग्रह के दौरान कचरा कलेक्टर की आवश्यकता होती है।

size एक ही रूप में उपयोग कर प्राप्त किए जा सकें है erlang:process_info(Pid, total_heap_size) , या जोड़कर heap_block_size , old_heap_block_size और mbuf_size से erlang:process_info(Pid, garbage_collection_info)

kill

जब सेट किया जाता है true , तो रनटाइम सिस्टम kill अधिकतम अचूक आकार तक पहुंचने पर प्रक्रिया के कारण एक अप्राप्य निकास संकेत भेजता है। ट्रिगर किया गया कचरा संग्रह kill पूरा नहीं हुआ है, इसके बजाय प्रक्रिया जितनी जल्दी हो सके बाहर निकल जाती है। जब सेट किया जाता है false , तो कोई एक्जिट सिग्नल प्रक्रिया को नहीं भेजा जाता है, इसके बजाय यह निष्पादित करना जारी रखता है।

यदि kill मानचित्र में परिभाषित नहीं किया गया है, तो सिस्टम डिफ़ॉल्ट का उपयोग किया जाएगा। डिफ़ॉल्ट सिस्टम डिफ़ॉल्ट है true । इसे या तो विकल्प +hmaxk में बदला जा सकता है erl(1) , या erlang:system_flag(max_heap_size, MaxHeapSize)

error_logger

जब सेट किया जाता है true , तो रनटाइम सिस्टम logger अधिकतम त्रुटि आकार तक पहुंचने पर प्रक्रिया के बारे में विवरण युक्त एक त्रुटि घटना को लॉग करता है। हर बार सीमा पूरी होने पर एक लॉग ईवेंट भेजा जाता है।

यदि error_logger मानचित्र में परिभाषित नहीं किया गया है, तो सिस्टम डिफ़ॉल्ट का उपयोग किया जाता है। डिफ़ॉल्ट सिस्टम डिफ़ॉल्ट है true । इसे या तो विकल्प +hmaxel int द्वारा बदला जा सकता है erl(1) , या erlang:system_flag(max_heap_size, MaxHeapSize)

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

process_flag (ध्वज :: message_queue_data, MQD) -> OldMQD

प्रकार

यह ध्वज निर्धारित करता है कि संदेश कतार में संदेश कैसे संग्रहीत किए जाते हैं, इस प्रकार है:

off_heap

संदेश कतार में सभी संदेश प्रक्रिया ढेर के बाहर संग्रहीत किए जाएंगे। इसका मतलब यह है कि संदेश कतार में कोई भी संदेश प्रक्रिया के कचरा संग्रह का हिस्सा नहीं होगा।

on_heap

संदेश कतार में सभी संदेश अंततः ढेर पर रखे जाएंगे। वे हालांकि अस्थायी रूप से ढेर से संग्रहीत किए जा सकते हैं। इस प्रकार ईआरटीएस 8.0 तक संदेशों को हमेशा संग्रहीत किया जाता है।

डिफ़ॉल्ट message_queue_data प्रक्रिया ध्वज को कमांड-लाइन तर्क द्वारा निर्धारित किया +hmqd जाता है erl(1)

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

इस ध्वज को बदलते समय संदेशों को ले जाया जाएगा। जब यह फ़ंक्शन कॉल करता है तो यह कार्य आरंभ किया गया है लेकिन पूरा नहीं हुआ है।

झंडे का पुराना मूल्य लौटाता है।

process_flag (ध्वज :: प्राथमिकता, स्तर) -> OldLevel

प्रकार

प्रक्रिया को प्राथमिकता देता है। Level एक परमाणु है। चार प्राथमिकता के स्तर मौजूद हैं: low , normal , high , और max । डिफ़ॉल्ट है normal

ध्यान दें

प्राथमिकता स्तर max Erlang रनटाइम सिस्टम में आंतरिक उपयोग के लिए आरक्षित है, और दूसरों द्वारा उपयोग नहीं किया जाना है।

आंतरिक रूप से प्रत्येक प्राथमिकता स्तर में, प्रक्रियाओं को एक रॉबिन फैशन में निर्धारित किया जाता है।

प्राथमिकता पर प्रक्रियाओं का निष्पादन normal और low अंतःक्षिप्त हैं। प्राथमिकता पर low प्रक्रियाओं को प्राथमिकता पर प्रक्रियाओं की तुलना में कम बार निष्पादन के लिए चुना जाता है normal

जब प्राथमिकता पर चलने योग्य प्रक्रियाएं high मौजूद होती हैं, तो प्राथमिकता पर कोई प्रक्रिया low या normal निष्पादन के लिए चयनित नहीं होती है । हालांकि ध्यान दें कि इसका मतलब यह नहीं है कि प्राथमिकता पर कोई प्रक्रिया नहीं चलती है low या normal जब प्रक्रियाएं प्राथमिकता पर चल रही हैं high । कई अनुसूचियों का उपयोग करते समय, प्राथमिकता पर प्रक्रियाओं की तुलना में समानांतर में अधिक प्रक्रियाएं चल सकती हैं high । यही है, एक low और एक high प्राथमिकता प्रक्रिया एक ही समय में निष्पादित हो सकती है।

प्राथमिकता के आधार पर runnable प्रक्रियाओं जब max प्राथमिकता के आधार पर मौजूद हैं, कोई प्रक्रियाओं low , normal या high निष्पादन के लिए चुने गए हैं। प्राथमिकता के साथ high , कम प्राथमिकताओं पर प्रक्रियाएं प्राथमिकता के आधार पर प्रक्रियाओं के साथ समानांतर में निष्पादित हो सकती हैं max

शेड्यूलिंग पूर्व-खाली है। प्राथमिकता के बावजूद, एक प्रक्रिया को पहले से खाली कर दिया जाता है जब अंतिम बार इसे निष्पादन के लिए चुने जाने के बाद से एक निश्चित संख्या से अधिक की खपत होती है।

ध्यान दें

शेड्यूलिंग पर निर्भर न रहें जैसा कि आज है। उपलब्ध प्रोसेसर कोर का बेहतर उपयोग करने के लिए भविष्य के रिलीज़ में शेड्यूलिंग को बदलने की संभावना है।

नहीं है कोई ऐसी प्राथमिकता विरासत या प्राथमिकता छत के रूप में, प्राथमिकता उलट से बचने के लिए स्वत: तंत्र। प्राथमिकताओं का उपयोग करते समय, इसे ध्यान में रखें और ऐसे परिदृश्यों को अपने आप से संभालें।

एक high प्राथमिकता प्रक्रिया से कोड में कॉल करना जो आपके पास कोई नियंत्रण नहीं है high कम प्राथमिकता वाली प्रक्रिया के लिए प्रतीक्षा करने के लिए प्राथमिकता प्रक्रिया का कारण बन सकता है। यही है, high कॉल के दौरान प्राथमिकता प्रक्रिया की प्राथमिकता को प्रभावी ढंग से कम कर रहा है । यहां तक ​​कि अगर यह कोड के एक संस्करण के साथ ऐसा नहीं है, जिस पर आपका कोई नियंत्रण नहीं है, तो यह भविष्य के संस्करण में ऐसा हो सकता है। उदाहरण के लिए, यह हो सकता है कि यदि कोई high प्राथमिकता प्रक्रिया कोड लोडिंग को ट्रिगर करती है, क्योंकि कोड सर्वर प्राथमिकता पर चलता है normal

normal सामान्य रूप से अन्य प्राथमिकताओं की आवश्यकता नहीं है। जब अन्य प्राथमिकताओं का उपयोग किया जाता है, तो उन्हें देखभाल के साथ उपयोग करें, विशेष रूप से प्राथमिकता high । प्राथमिकता पर एक प्रक्रिया high केवल छोटी अवधि के लिए काम करने के लिए है। high प्राथमिकता प्रक्रिया में लंबी अवधि के लिए व्यस्त लूपिंग सबसे संभावित समस्याओं का कारण बनता है, क्योंकि महत्वपूर्ण ओटीपी सर्वर प्राथमिकता पर चलते हैं normal

झंडे का पुराना मूल्य लौटाता है।

process_flag (ध्वज :: save_calls, N) -> OldN

प्रकार

N अंतराल में एक पूर्णांक होना चाहिए 0..10000। यदि N > 0, कॉल सेविंग प्रक्रिया के लिए सक्रिय है। इसका मतलब यह है कि N प्रक्रिया द्वारा किए गए सबसे हालिया वैश्विक फ़ंक्शन कॉल, बीआईएफ कॉल, भेजता है, और प्राप्त करने की जानकारी एक सूची में सहेजी जाती है, जिसके साथ पुनर्प्राप्त किया जा सकता है process_info(Pid, last_calls) । एक वैश्विक फ़ंक्शन कॉल वह है जिसमें फ़ंक्शन के मॉड्यूल का स्पष्ट रूप से उल्लेख किया गया है। केवल एक निश्चित मात्रा में जानकारी बचाई गई है, इस प्रकार है:

  • {Module, Function, Arity} फ़ंक्शन कॉल के लिए एक ट्यूपल

  • परमाणु send , 'receive' और timeout भेजता है और प्राप्त करता है ( 'receive' जब एक संदेश प्राप्त होता है और timeout जब एक बार प्राप्त होता है)

यदि N = 0, कॉल बचत प्रक्रिया के लिए अक्षम है, जो डिफ़ॉल्ट है। जब भी कॉल सेविंग लिस्ट का आकार निर्धारित किया जाता है, तो इसकी सामग्री रीसेट हो जाती है।

झंडे का पुराना मूल्य लौटाता है।

process_flag (ध्वज :: संवेदनशील, बूलियन) -> OldBoolean

प्रकार

sensitive वर्तमान प्रक्रिया के लिए ध्वज सेट या साफ़ करता है। जब किसी प्रक्रिया को कॉल करके संवेदनशील के रूप में चिह्नित किया जाता process_flag(sensitive, true) है, तो रनटाइम सिस्टम में विशेषताएं जो डेटा की जांच करने के लिए उपयोग की जा सकती हैं या प्रक्रिया के आंतरिक काम चुपचाप अक्षम हैं।

जो सुविधाएँ अक्षम हैं उनमें निम्नलिखित शामिल हैं (लेकिन इन तक सीमित नहीं हैं):

  • ट्रेसिंग। ट्रेस झंडे अभी भी प्रक्रिया के लिए सेट किए जा सकते हैं, लेकिन किसी भी तरह के कोई भी संदेश उत्पन्न नहीं होते हैं। (यदि झंडा sensitive बंद कर दिया जाता है, तो ट्रेस संदेश फिर से उत्पन्न होते हैं यदि कोई ट्रेस ध्वज सेट हो।)

  • अनुक्रमिक अनुरेखण। अनुक्रमिक ट्रेस टोकन को हमेशा की तरह प्रचारित किया जाता है, लेकिन कोई अनुक्रमिक ट्रेस संदेश उत्पन्न नहीं होता है।

process_info/1,2 संदेश कतार या प्रक्रिया शब्दकोश (दोनों खाली सूची के रूप में लौटाए जाते हैं) को पढ़ने के लिए उपयोग नहीं किया जा सकता है।

प्रक्रिया के लिए स्टैक बैक-ट्रेस प्रदर्शित नहीं किए जा सकते।

क्रैश डंप में, स्टैक, संदेश और प्रक्रिया शब्दकोश को छोड़ दिया जाता है।

यदि {save_calls,N} इस प्रक्रिया के लिए सेट किया गया है, तो कोई फ़ंक्शन कॉल कॉल बचत सूची में सहेजे नहीं जाते हैं। (कॉल सेविंग लिस्ट को क्लियर नहीं किया गया है। इसके अलावा, भेजें, प्राप्त करें, और टाइम-आउट ईवेंट्स अभी भी सूची में जोड़े गए हैं।)

झंडे का पुराना मूल्य लौटाता है।

process_flag (Pid, Flag, Value) -> OldValue

प्रकार

प्रक्रिया के लिए कुछ झंडे सेट करता है Pid , उसी तरह से process_flag/2 । झंडे का पुराना मूल्य लौटाता है। के लिए मान्य मान Flag केवल उन अनुमतियों का एक सबसेट हैं, जिनके process_flag/2 नाम हैं save_calls

विफलता: badarg यदि Pid एक स्थानीय प्रक्रिया नहीं है।

process_info (Pid) -> जानकारी

प्रकार

एक सूची देता है जिसकी InfoTuple पहचान प्रक्रिया के बारे में विविध जानकारी के साथ होती है Pid , या undefined यदि प्रक्रिया जीवित नहीं है

एस का क्रम InfoTuple अपरिभाषित है और सभी InfoTuple एस अनिवार्य नहीं हैं। InfoTuple परिणाम के भाग पूर्व सूचना के बिना बदला जा सकता है।

InfoTuple निम्नलिखित मदों के साथ परिणाम का हिस्सा हैं:

  • current_function
  • initial_call
  • status
  • message_queue_len
  • links
  • dictionary
  • trap_exit
  • error_handler
  • priority
  • group_leader
  • total_heap_size
  • heap_size
  • stack_size
  • reductions
  • garbage_collection

यदि पहचान की गई प्रक्रिया Pid में एक पंजीकृत नाम है, तो एक InfoTuple आइटम registered_name भी शामिल है।

विशिष्ट InfoTuple एस के बारे में जानकारी के लिए , देखें process_info/2

चेतावनी

यह बीआईएफ केवल डिबगिंग के लिए है । अन्य सभी उद्देश्यों के लिए, उपयोग करें process_info/2

विफलता: badarg यदि Pid एक स्थानीय प्रक्रिया नहीं है।

process_info (Pid, आइटम) -> InfoTuple | [] | अपरिभाषित
process_info (Pid, ItemList) -> InfoTupleList | [] | अपरिभाषित

प्रकार

Pid द्वारा Item या के रूप में निर्दिष्ट की गई प्रक्रिया के बारे में जानकारी देता है ItemList undefined यदि प्रक्रिया जीवित नहीं है, तो लौटाता है।

यदि प्रक्रिया जीवित है और एक Item निर्दिष्ट है, तो लौटाया गया मूल्य InfoTuple तब तक संबंधित होता है , जब तक कि Item =:= registered_name इस प्रक्रिया का कोई पंजीकृत नाम न हो। इस मामले में, [] वापस कर दिया जाता है। यह अजीब व्यवहार ऐतिहासिक कारणों से है, और पिछड़े संगतता के लिए रखा गया है।

यदि ItemList निर्दिष्ट किया गया है, तो परिणाम है InfoTupleList InfoTuple में InfoTupleList इसी के साथ शामिल हैं Item के रूप में एक ही क्रम में रों Item रों में शामिल थे ItemList । वैध Item एस को कई बार में शामिल किया जा सकता है ItemList

ध्यान दें

यदि registered_name का हिस्सा है ItemList और इस प्रक्रिया का कोई नाम पंजीकृत नहीं है {registered_name, []} , तो परिणाम में शामिल किया InfoTuple जाएगा InfoTupleList । यह व्यवहार अलग है जब एक एकल Item =:= registered_name निर्दिष्ट process_info/1 किया जाता है , और जब उपयोग किया जाता है।

InfoTuple संगत s के साथ मान्य है Item :

{backtrace, Bin}

बाइनरी Bin में आउटपुट से समान जानकारी होती है erlang:process_display(Pid, backtrace) binary_to_list/1 बाइनरी से वर्णों की स्ट्रिंग प्राप्त करने के लिए उपयोग करें ।

{binary, BinInfo}

BinInfo इस प्रक्रिया के ढेर पर बायनेरिज़ के बारे में विविध जानकारी वाली एक सूची है। इसे InfoTuple बिना पूर्व सूचना के बदला या हटाया जा सकता है। वर्तमान कार्यान्वयन BinInfo में tuples की एक सूची है। टुपल्स होते हैं; BinaryId , BinarySize , BinaryRefcCount

संदेश ध्वज प्रक्रिया ध्वज के आधार पर ढेर पर है message_queue_data

{catchlevel, CatchLevel}

CatchLevel इस प्रक्रिया में वर्तमान में सक्रिय कैच की संख्या है। इसे InfoTuple बिना पूर्व सूचना के बदला या हटाया जा सकता है।

{current_function, {Module, Function, Arity}}

Module , Function , Arity प्रक्रिया की वर्तमान समारोह कॉल है।

{current_location, {Module, Function, Arity, Location}}

Module , Function , Arity प्रक्रिया की वर्तमान समारोह कॉल है। Location स्रोत कोड में स्थान का वर्णन करने वाले दो-टुपल्स की एक सूची है।

{current_stacktrace, Stack}

प्रक्रिया के वर्तमान कॉल स्टैक बैक-ट्रेस ( स्टैकट्रेस ) को लौटाता है। स्टैक के पास उसी प्रारूप में होता है, जो उसके द्वारा लौटाया जाता है erlang:get_stacktrace/0 backtrace_depth सिस्टम फ्लैग सेटिंग के अनुसार स्टैकट्रेस की गहराई को काट दिया जाता है ।

{dictionary, Dictionary}

Dictionary प्रक्रिया शब्दकोश है।

{error_handler, Module}

Module प्रक्रिया द्वारा प्रयुक्त त्रुटि हैंडलर मॉड्यूल है (उदाहरण के लिए अपरिभाषित फ़ंक्शन कॉल)।

{garbage_collection, GCInfo}

GCInfo इस प्रक्रिया के लिए कचरा संग्रहण के बारे में विविध जानकारी वाली एक सूची है। GCInfo बिना पूर्व सूचना के सामग्री को बदला जा सकता है।

{garbage_collection_info, GCInfo}

GCInfo इस प्रक्रिया के लिए कचरा संग्रहण के बारे में विविध विस्तृत जानकारी वाली एक सूची है। GCInfo बिना पूर्व सूचना के सामग्री को बदला जा सकता है। प्रत्येक आइटम के अर्थ के बारे में विवरण के लिए, देखें gc_minor_start में erlang:trace/3

{group_leader, GroupLeader}

GroupLeader प्रक्रिया के I / O के लिए समूह का नेता है।

{heap_size, Size}

Size प्रक्रिया के सबसे कम उम्र की पीढ़ी के शब्दों में आकार है। इस पीढ़ी में प्रक्रिया स्टैक शामिल है। यह जानकारी अत्यधिक कार्यान्वयन-निर्भर है, और यदि कार्यान्वयन में परिवर्तन होता है तो बदल सकता है।

{initial_call, {Module, Function, Arity}}

Module , Function , Arity प्रारंभिक समारोह कॉल जिसके साथ प्रक्रिया पैदा किया गया है।

{links, PidsAndPorts}

PidsAndPorts प्रक्रिया पहचानकर्ताओं और बंदरगाह पहचानकर्ताओं की एक सूची है, प्रक्रियाओं या बंदरगाहों के साथ जिनके लिए प्रक्रिया की एक कड़ी है।

{last_calls, false|Calls}

मान false अगर कॉल सेविंग प्रक्रिया के लिए सक्रिय नहीं है (देखें process_flag/3 )। यदि कॉल सेविंग सक्रिय है, तो एक सूची दी जाती है, जिसमें अंतिम तत्व सबसे हाल ही में कहा जाता है।

{memory, Size}

Size प्रक्रिया के बाइट्स में आकार है। इसमें कॉल स्टैक, हीप और आंतरिक संरचना शामिल हैं।

{message_queue_len, MessageQueueLen}

MessageQueueLen इस प्रक्रिया की संदेश कतार में वर्तमान में संदेशों की संख्या है। यह MessageQueue सूचना आइटम के रूप में लौटी सूची की लंबाई है messages (नीचे देखें)।

{messages, MessageQueue}

MessageQueue प्रक्रिया के लिए उन संदेशों की एक सूची है, जिन्हें अभी तक संसाधित नहीं किया गया है।

{min_heap_size, MinHeapSize}

MinHeapSize प्रक्रिया के लिए न्यूनतम हीप आकार है।

{min_bin_vheap_size, MinBinVHeapSize}

MinBinVHeapSize प्रक्रिया के लिए न्यूनतम बाइनरी वर्चुअल हीप आकार है।

{monitored_by, Pids}

प्रक्रिया की पहचान करने वाले प्रक्रिया की निगरानी करने वाली सूची (के साथ monitor/2 )।

{monitors, Monitors}

मॉनिटर की एक सूची (द्वारा शुरू monitor/2 ) जो प्रक्रिया के लिए सक्रिय है। स्थानीय प्रक्रिया मॉनिटर या किसी प्रक्रिया पहचानकर्ता द्वारा दूरस्थ प्रक्रिया मॉनिटर के लिए, सूची में निम्न शामिल हैं:

{process, Pid}
प्रक्रिया की निगरानी पीआईडी ​​द्वारा की जाती है।
{process, {RegName, Node}}
स्थानीय या दूरस्थ प्रक्रिया नाम से निगरानी की जाती है।
{port, PortId}
पोर्ट आईडी से लोकल पोर्ट की निगरानी की जाती है।
{port, {RegName, Node}}
स्थानीय पोर्ट नाम से निगरानी की जाती है। कृपया ध्यान दें, दूरस्थ पोर्ट मॉनिटर समर्थित नहीं हैं, इसलिए Node हमेशा स्थानीय नोड नाम होगा।
{message_queue_data, MQD}

प्रक्रिया ध्वज की वर्तमान स्थिति देता है message_queue_data । या MQD तो है । अधिक जानकारी के लिए, का प्रलेखन देखें । off_heap on_heap process_flag(message_queue_data, MQD)

{priority, Level}

Level प्रक्रिया के लिए वर्तमान प्राथमिकता स्तर है। प्राथमिकताओं के बारे में अधिक जानकारी के लिए, देखें process_flag(priority, Level)

{reductions, Number}

Number प्रक्रिया द्वारा निष्पादित कटौती की संख्या है।

{registered_name, Atom}

Atom पंजीकृत प्रक्रिया का नाम है। यदि प्रक्रिया में कोई पंजीकृत नाम नहीं है, तो यह टपल सूची में मौजूद नहीं है।

{sequential_trace_token, [] | SequentialTraceToken}

SequentialTraceToken इस प्रक्रिया के लिए अनुक्रमिक निशान टोकन है। इसे InfoTuple बिना पूर्व सूचना के बदला या हटाया जा सकता है।

{stack_size, Size}

Size स्टैक आकार है, शब्दों में, प्रक्रिया का।

{status, Status}

Status प्रक्रिया की स्थिति है और निम्नलिखित में से एक है:

  • exiting
  • garbage_collecting
  • waiting (एक संदेश के लिए)
  • running
  • runnable (चलाने के लिए तैयार है, लेकिन एक और प्रक्रिया चल रही है)
  • suspended ("व्यस्त" पोर्ट पर या BIF द्वारा निलंबित erlang:suspend_process/1,2 )
{suspending, SuspendeeList}

SuspendeeList {Suspendee, ActiveSuspendCount, OutstandingSuspendCount} tuples की एक सूची है । Suspendee एक प्रक्रिया की प्रक्रिया पहचानकर्ता है Pid जो बीआईएफ erlang:suspend_process/2 या के माध्यम से पहचान की गई प्रक्रिया द्वारा निलंबित, या की गई है erlang:suspend_process/1

ActiveSuspendCount कितनी बार Suspendee निलंबित किया गया है Pid OutstandingSuspendCount द्वारा भेजे गए सस्पेंड अनुरोधों की संख्या अभी तक नहीं है Pid , जो है:

  • यदि ActiveSuspendCount =/= 0 , Suspendee वर्तमान में निलंबित अवस्था में है।

  • यदि OutstandingSuspendCount =/= 0 , विकल्प asynchronous का erlang:suspend_process/2 उपयोग किया गया है और निलंबन को अभी तक निलंबित नहीं किया गया है Pid

ध्यान दें कि ActiveSuspendCount और OutstandingSuspendCount कुल सस्पेंड काउंट नहीं हैं Suspendee , केवल उन हिस्सों द्वारा योगदान दिया गया है Pid

{total_heap_size, Size}

Size कुल आकार, शब्दों में, प्रक्रिया के सभी ढेर के टुकड़े हैं। इसमें प्रक्रिया स्टैक और किसी भी अप्रतिबंधित संदेश शामिल हैं जिन्हें ढेर का हिस्सा माना जाता है।

{trace, InternalTraceFlags}

InternalTraceFlags इस प्रक्रिया के लिए आंतरिक ट्रेस ध्वज का प्रतिनिधित्व करने वाला पूर्णांक है। इसे InfoTuple बिना पूर्व सूचना के बदला या हटाया जा सकता है।

{trap_exit, Boolean}

Boolean है true अगर प्रक्रिया बाहर निकलता है फँसाने होता है, वरना false

ध्यान दें कि सभी कार्यान्वयन इन सभी का समर्थन नहीं करते हैं Item

विफलताएं:

badarg
यदि Pid एक स्थानीय प्रक्रिया नहीं है।
badarg
यदि Item कोई अमान्य आइटम है।
प्रक्रियाएँ () -> [पीआईडी ​​()]

स्थानीय नोड पर वर्तमान में मौजूद सभी प्रक्रियाओं के अनुरूप प्रक्रिया पहचानकर्ताओं की सूची लौटाता है।

ध्यान दें कि एक बाहर निकलने की प्रक्रिया मौजूद है, लेकिन जीवित नहीं है। यही है, एक बाहर निकलने की प्रक्रिया के लिए is_process_alive/1 रिटर्न false , लेकिन इसकी प्रक्रिया पहचानकर्ता से लौटे परिणाम का हिस्सा है processes/0

उदाहरण:

> processes().
[<0.0.0>,<0.2.0>,<0.4.0>,<0.5.0>,<0.7.0>,<0.8.0>]
purge_module (मॉड्यूल) -> सच है

प्रकार

के लिए पुराना कोड निकाल देता है Module । इससे पहले कि बीआईएफ का उपयोग किया जाता है, check_process_code/2 यह जांचने के लिए बुलाया जाए कि कोई भी प्रक्रिया मॉड्यूल में पुराने कोड को निष्पादित नहीं करती है।

चेतावनी

यह BIF कोड सर्वर के लिए अभिप्रेत है (देखें code(3) ) और अन्यत्र उपयोग नहीं किया जाना है।

ध्यान दें

ERTS 8.0 (Erlang / OTP 19) से, कोई भी सुस्त प्रक्रिया जो अभी भी पुराने कोड को निष्पादित करती है, इस फ़ंक्शन द्वारा मार दी जाती है। पहले के संस्करणों में, इस तरह के गलत उपयोग से एमुलेटर क्रैश जैसी अधिक घातक विफलताएं हो सकती हैं।

विफलता: badarg यदि कोई पुराना कोड नहीं है Module

डाल (की, वैल) -> टर्म ()

प्रकार

Key मान Val , और रिटर्न से संबंधित प्रक्रिया शब्दकोश में एक नया जोड़ता है undefined । यदि Key मौजूद है, तो पुराना मान हटा दिया जाता है Val और उसके द्वारा प्रतिस्थापित किया जाता है , और फ़ंक्शन पुराना मान लौटाता है। उदाहरण:

> X = put(name, walrus), Y = put(name, carpenter),
Z = get(name),
{X, Y, Z}.
{undefined,walrus,carpenter}
ध्यान दें

जब put एक मूल्यांकन के दायरे में मूल्यांकन किया जाता है, तो संग्रहीत किए गए मानों का मूल्यांकन catch नहीं throw किया जाता है यदि कोई मूल्यांकन किया जाता है, या यदि कोई त्रुटि होती है

erlang: उठाना (क्लास, रीज़न, स्टैक्ट्रेस) -> no_return ()

प्रकार

निर्दिष्ट वर्ग, कारण और कॉल स्टैक बैकट्रेस ( स्टैकट्रेस ) के अपवाद के साथ कॉलिंग प्रक्रिया के निष्पादन को रोक देता है ।

Class है error , exit या throw । तो, अगर यह स्टैकट्रेस के लिए नहीं था, तो इसके erlang:raise(Class, Reason, Stacktrace) बराबर है erlang:Class(Reason)

Reason कोई भी शब्द है Stacktrace के रूप में लौटा है get_stacktrace() , यानी, चार-नलिकाओं की एक सूची है {Module, Function, Arity | Args, Location} , जहां Module और Function परमाणु हैं, और तीसरा तत्व एक पूर्णांक या तर्क सूची है। स्टैकट्रेस में टुपल्स भी हो सकते हैं {Fun, Args, Location} , जहां Fun एक स्थानीय मज़ा है और Args एक तर्क सूची है।

Location अंत में तत्व वैकल्पिक है। इसे छोड़ना एक खाली सूची को निर्दिष्ट करने के बराबर है।

स्टैकट्रेस का उपयोग कॉलिंग प्रक्रिया के अपवाद स्टैकट्रेस के रूप में किया जाता है; इसे वर्तमान अधिकतम स्टैकट्रेस गहराई तक काट दिया जाता है।

चूंकि इस फ़ंक्शन का मूल्यांकन करने की प्रक्रिया समाप्त हो जाती है, इसका कोई रिटर्न मान नहीं है जब तक कि तर्क अमान्य नहीं होते हैं, उस स्थिति में फ़ंक्शन त्रुटि कारण देता है badarg । यदि आप सुनिश्चित हैं कि आप वापस नहीं लौटना चाहते हैं, तो आप कॉल कर सकते हैं error(erlang:raise(Class, Reason, Stacktrace)) और बाद में अपवादों को अलग करने की उम्मीद कर सकते हैं ।

erlang: read_timer (TimerRef) -> परिणाम

प्रकार

एक टाइमर की स्थिति पढ़ता है। बुला के समान erlang:read_timer/2

erlang: read_timer (TimerRef, Options) -> परिणाम | ठीक

प्रकार

एक टाइमर की स्थिति को पढ़ता है जिसे या तो बनाया गया है erlang:start_timer या erlang:send_after TimerRef टाइमर की पहचान करता है, और टाइमर बनाने वाले BIF द्वारा लौटाया गया था।

Options :

{async, Async}

राज्य की जानकारी के लिए अतुल्यकालिक अनुरोध। Async के लिए चूक false , जिसके कारण ऑपरेशन को सिंक्रोनाइज़ किया जा सकता है। इस मामले में, Result द्वारा वापस कर दिया जाता है erlang:read_timer । जब Async होता है true , erlang:read_timer तो टाइमर का प्रबंधन करने वाली टाइमर सेवा को राज्य सूचना के लिए एक अतुल्यकालिक अनुरोध भेजता है, और फिर लौटता है ok । जब कार्रवाई की गई है {read_timer, TimerRef, Result} , erlang:read_timer तो कॉल करने वाले को प्रारूप पर एक संदेश भेजा जाता है।

Option भविष्य में और अधिक जोड़े जा सकते हैं।

यदि Result पूर्णांक है, तो यह टाइमर के समाप्त होने तक बचे हुए मिलीसेकंड में समय का प्रतिनिधित्व करता है।

यदि Result है false , तो एक टाइमर के अनुरूप TimerRef नहीं पाया जा सकता है। ऐसा इसलिए है क्योंकि टाइमर की समय सीमा समाप्त हो गई थी, या रद्द कर दी गई थी, या क्योंकि TimerRef कभी भी टाइमर के अनुरूप नहीं था। भले ही टाइमर समाप्त हो गया है, यह आपको यह नहीं बताता है कि अभी तक समय-आउट संदेश अपने गंतव्य पर आया है या नहीं।

ध्यान दें

टाइमर को प्रबंधित करने वाली टाइमर सेवा को शेड्यूलर की तुलना में किसी अन्य शेड्यूलर के साथ सह-स्थित किया जा सकता है जिसे कॉलिंग प्रक्रिया निष्पादित कर रही है। यदि ऐसा है, तो टाइमर सेवा के साथ संचार स्थानीय समय की तुलना में अधिक समय लेता है। यदि कॉलिंग प्रक्रिया एक महत्वपूर्ण पथ में है, और इस ऑपरेशन के परिणाम की प्रतीक्षा करते समय अन्य चीजें कर सकते हैं, तो आप विकल्प का उपयोग करना चाहते हैं {async, true} । यदि विकल्प का उपयोग किया जाता है {async, false} , तो कॉलिंग प्रक्रिया अवरुद्ध हो जाती है जब तक कि ऑपरेशन नहीं किया गया हो।

यह भी देखें erlang:send_after , erlang:start_timer , और erlang:cancel_timer/2

Ref_to_list (Ref) -> स्ट्रिंग ()

प्रकार

के पाठ प्रतिनिधित्व के अनुरूप एक स्ट्रिंग लौटाता है Ref

चेतावनी

यह BIF डिबगिंग के लिए अभिप्रेत है और इसका उपयोग एप्लिकेशन प्रोग्राम में नहीं किया जाता है

रजिस्टर (RegName, PidOrPort) -> सच है

प्रकार

RegName एक प्रक्रिया पहचानकर्ता (पीआईडी) या एक बंदरगाह पहचानकर्ता के साथ नाम को संबद्ध करता है । RegName , जो कि एक परमाणु होना चाहिए, का उपयोग पिड या पोर्ट आइडेंटिफायर के बजाय सेंड ऑपरेटर ( RegName ! Message ) में किया जा सकता है । उदाहरण:

> register(db, Pid).
true

विफलताएं:

badarg
यदि PidOrPort कोई मौजूदा स्थानीय प्रक्रिया या पोर्ट नहीं है।
badarg
यदि RegName पहले से उपयोग में है।
badarg
यदि प्रक्रिया या पोर्ट पहले से पंजीकृत है (पहले से ही एक नाम है)।
badarg
अगर RegName परमाणु है undefined
पंजीकृत () -> [RegName]

प्रकार

register/2 उदाहरण के लिए, पंजीकृत नामों की सूची लौटाता है :

> registered().
[code_server, file_server, init, user, my_db]
erlang: resume_process (Suspendee) -> सच

प्रकार

द्वारा पहचानी गई प्रक्रिया पर सस्पेंड काउंट घटाता है Suspendee Suspendee पहले से कॉलिंग प्रक्रिया के माध्यम से erlang:suspend_process/2 या निलंबित कर दिया गया है । जब सस्पेंड की संख्या शून्य तक पहुंच जाती है, तो फिर से शुरू किया जाता है, अर्थात, इसका राज्य निलंबित होने से पहले इसे उस राज्य में बदल दिया जाता है। erlang:suspend_process/1 erlang:resume_process(Suspendee) Suspendee Suspendee

चेतावनी

यह बीआईएफ केवल डिबगिंग के लिए है।

विफलताएं:

badarg
यदि Suspendee एक प्रक्रिया पहचानकर्ता नहीं है।
badarg
यदि प्रक्रिया कॉलिंग erlang:resume_process/1 ने पहले पहचानी गई प्रक्रिया पर निलंबित गणना नहीं बढ़ाई थी Suspendee
badarg
यदि पहचान की गई प्रक्रिया Suspendee जीवित नहीं है।
दौर (संख्या) -> पूर्णांक ()

प्रकार

Number उदाहरण के लिए, पूर्णांक द्वारा पूर्णांक लौटाता है :

round(5.5).
6

गार्ड परीक्षण में अनुमति है।

स्वयं () -> पिड ()

उदाहरण के लिए, कॉलिंग प्रक्रिया की प्रक्रिया पहचानकर्ता लौटाता है:

> self().
<0.26.0>

गार्ड परीक्षण में अनुमति है।

erlang: सेंड (डेस्ट, मिसग) -> Msg

प्रकार

एक संदेश भेजता है और लौटता है Msg । इस का उपयोग कर के रूप में ही है send operator : Dest ! Msg

Dest एक दूरस्थ या स्थानीय प्रक्रिया पहचानकर्ता, एक (स्थानीय) पोर्ट, स्थानीय रूप से पंजीकृत नाम या किसी {RegName, Node} अन्य नोड के लिए पंजीकृत नाम के लिए टपल हो सकता है।

badarg यदि Dest कोई परमाणु नाम है, तो रन-टाइम त्रुटि के साथ फ़ंक्शन विफल रहता है, लेकिन यह नाम पंजीकृत नहीं है। यह एकमात्र ऐसा मामला है जब send एक अप्राप्य गंतव्य Dest (सही प्रकार का) के लिए विफल रहता है ।

erlang: भेजें (गंतव्य, संदेश, विकल्प) -> Res

प्रकार

या तो एक संदेश और रिटर्न भेजता है ok , या संदेश नहीं भेजता है लेकिन कुछ और लौटाता है (नीचे देखें)। अन्यथा के रूप में ही erlang:send/2 । अधिक विस्तृत विवरण और चेतावनी के लिए, देखें erlang:send_nosuspend/2,3

विकल्प:

nosuspend
यदि प्रेषक को भेजने के लिए निलंबित करना होगा, तो nosuspend इसके बजाय वापस कर दिया जाएगा।
noconnect
यदि गंतव्य नोड को भेजने के लिए स्वत: कनेक्ट होना होगा, तो noconnect इसके बजाय वापस कर दिया जाएगा।
चेतावनी

जैसा कि erlang:send_nosuspend/2,3 : अत्यधिक देखभाल के साथ उपयोग करें।

erlang: send_after (समय, गंतव्य, Msg) -> टाइमर

प्रकार

एक टाइमर शुरू करता है। बुला के समान erlang:send_after

erlang: send_after (समय, गंतव्य, संदेश, विकल्प) -> टाइमर

प्रकार

एक टाइमर शुरू करता है। जब टाइमर समाप्त हो जाता है, तो संदेश Msg द्वारा पहचानी गई प्रक्रिया को भेजा जाता है Dest । टाइम-आउट संदेश के प्रारूप के अलावा, यह फ़ंक्शन ठीक उसी तरह काम करता है erlang:start_timer

erlang: send_nosuspend (गंतव्य, Msg) -> बूलियन ()

प्रकार

के रूप में ही है erlang:send(Dest,Msg, [nosuspend]) , लेकिन true अगर संदेश भेजा गया था और false अगर संदेश नहीं भेजा गया था क्योंकि रिटर्न प्रेषक को निलंबित करना होगा।

यह फ़ंक्शन बिना भेजे (Erlang) प्रक्रिया को अवरुद्ध किए बिना एक अविश्वसनीय दूरस्थ नोड में ऑपरेशन भेजने के लिए लक्षित है। यदि रिमोट नोड से कनेक्शन (आमतौर पर एक वास्तविक एरलंग नोड नहीं है, लेकिन सी या जावा में लिखा नोड) अतिभारित है, तो यह फ़ंक्शन संदेश और रिटर्न नहीं भेजता है false

वही होता है यदि Dest एक स्थानीय पोर्ट को संदर्भित करता है जो व्यस्त है। अन्य सभी गंतव्यों (साधारण भेजने वाले ऑपरेटर के लिए अनुमति दी गई '!' ) के लिए, यह फ़ंक्शन संदेश और रिटर्न भेजता है true

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

ध्यान दें कि इस फ़ंक्शन से रिटर्न वैल्यू को अनदेखा करने से एक अविश्वसनीय संदेश पारित हो जाएगा, जो कि एरलांग प्रोग्रामिंग मॉडल के विरोधाभासी है। यह फ़ंक्शन वापस आने पर संदेश नहीं भेजा जाता है false

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

चेतावनी

अत्यधिक देखभाल के साथ उपयोग करें।

erlang: send_nosuspend (गंतव्य, संदेश, विकल्प) -> बूलियन ()

प्रकार

के रूप में ही है erlang:send(Dest,Msg, [nosuspend |Options]) , लेकिन एक बूलियन वापसी मूल्य के साथ।

यह फ़ंक्शन जैसा व्यवहार करता है erlang:send_nosuspend/2,3 , लेकिन एक तीसरा पैरामीटर लेता है, विकल्पों की एक सूची। एकमात्र विकल्प है noconnect , जो फ़ंक्शन को वापस करता है false यदि दूरस्थ नोड वर्तमान में स्थानीय नोड द्वारा उपलब्ध नहीं है। सामान्य व्यवहार नोड से कनेक्ट करने का प्रयास करना है, जो छोटी अवधि के दौरान प्रक्रिया को रोक सकता है। विकल्प का उपयोग noconnect यह सुनिश्चित करना संभव बनाता है कि किसी दूरस्थ प्रक्रिया को भेजते समय थोड़ी सी भी देरी न हो। यह विशेष रूप से उपयोगी है जब नोड्स के साथ संचार किया जाता है जो हमेशा कनेक्टिंग भाग (यानी, सी या जावा में लिखे नोड्स) होने की उम्मीद करते हैं।

जब भी फ़ंक्शन लौटता है false (या तो जब कोई सस्पेंड होगा या जब noconnect निर्दिष्ट किया गया था और नोड पहले से कनेक्ट नहीं था), तो संदेश की गारंटी है कि नहीं भेजा गया है।

चेतावनी

अत्यधिक देखभाल के साथ उपयोग करें।

erlang: set_cookie (नोड, कुकी) -> सच

प्रकार

Node परमाणु के जादू कुकी सेट करता है Cookie । यदि Node स्थानीय नोड है, तो फ़ंक्शन अन्य सभी अज्ञात नोड्स के कुकी को भी सेट करता है Cookie ( Distributed Erlang सिस्टम प्रलेखन में एर्लांग संदर्भ मैनुअल में अनुभाग देखें )।

विफलता: function_clause यदि स्थानीय नोड जीवित नहीं है।

सेटेलमेंट (इंडेक्स, टपल 1, मान) -> टुप्ले 2

प्रकार

1..tuple_size (Tuple1

एक टपल लौटाता है जो Tuple1 पूर्णांक तर्क द्वारा निर्दिष्ट तत्व के साथ तर्क की एक प्रति है Index (पहला तत्व सूचकांक के साथ तत्व है) तर्क द्वारा प्रतिस्थापित किया गया है Value , उदाहरण के लिए:

> setelement(2, {10, green, bottles}, red).
{10,red,bottles}
आकार (आइटम) -> पूर्णांक ()> = 0

प्रकार

टपल में तत्वों की संख्या या बाइनरी या बिटस्ट्रिंग में बाइट्स की संख्या उदाहरण के लिए देता है:

> size({morni, mulle, bwange}).
3
> size(<<11, 22, 33>>).
3

बिटस्ट्रिंग्स के लिए, पूरे बाइट्स की संख्या वापस आ जाती है। यही है, अगर बिटस्ट्रिंग में बिट्स की संख्या 8 से विभाज्य नहीं है, तो परिणामस्वरूप बाइट्स की संख्या नीचे गोल है

गार्ड परीक्षण में अनुमति है।

यह भी देखें tuple_size/1 , byte_size/1 , और bit_size/1

स्पॉन (मज़ा) -> पिड ()

प्रकार

Fun खाली सूची के आवेदन द्वारा शुरू की गई एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता को लौटाता है [] । अन्यथा की तरह काम करता है spawn/3

स्पॉन (नोड, फन) -> पिड ()

प्रकार

के आवेदन के द्वारा शुरू कर दिया एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता रिटर्न Fun खाली सूची [] पर Node । यदि Node मौजूद नहीं है, तो एक बेकार पीआईडी ​​वापस आ जाती है। अन्यथा की तरह काम करता है spawn/3

स्पॉन (मॉड्यूल, फंक्शन, आर्ग्स) -> पिड ()

प्रकार

के अनुप्रयोग द्वारा शुरू की गई एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता को लौटाता Module:Function है Args

error_handler:undefined_function(Module, Function, Args) नई प्रक्रिया द्वारा मूल्यांकन किया जाता है यदि Module:Function/Arity मौजूद नहीं है (जहां Arity लंबाई है Args )। त्रुटि हैंडलर को फिर से परिभाषित किया जा सकता है (देखें process_flag/2 )। यदि error_handler अपरिभाषित है, या उपयोगकर्ता ने डिफ़ॉल्ट को फिर से परिभाषित किया है error_handler और इसका प्रतिस्थापन अपरिभाषित है, तो कारण के साथ विफलता undef होती है।

उदाहरण:

> spawn(speed, regulator, [high_speed, thin_cut]).
<0.13.1>
स्पॉन (नोड, मॉड्यूल, फंक्शन, आर्ग्स) -> पिड ()

प्रकार

एक नई प्रक्रिया के प्रोसेस आइडेंटिफ़ायर (pid) Module:Function को Args ऑन करके शुरू की गई एक नई प्रक्रिया का रिटर्न देता है Node । यदि Node मौजूद नहीं है, तो एक बेकार पीआईडी ​​वापस आ जाती है। अन्यथा की तरह काम करता है spawn/3

स्पॉन_लिंक (मज़ा) -> पिड ()

प्रकार

Fun खाली सूची के आवेदन द्वारा शुरू की गई एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता को लौटाता है [] । कॉलिंग प्रक्रिया और नई प्रक्रिया के बीच, एटोमिक रूप से एक लिंक बनाया जाता है। अन्यथा की तरह काम करता है spawn/3

स्पॉन_लिंक (नोड, फन) -> पिड ()

प्रकार

के आवेदन के द्वारा शुरू कर दिया एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता (पीआईडी) रिटर्न Fun खाली सूची [] पर Node । कॉलिंग प्रक्रिया और नई प्रक्रिया के बीच, एटोमिक रूप से एक लिंक बनाया जाता है। यदि Node मौजूद नहीं है, तो एक बेकार पीआईडी ​​वापस आ जाती है और कारण के साथ एक निकास संकेत noconnection कॉलिंग प्रक्रिया को भेजा जाता है। अन्यथा की तरह काम करता है spawn/3

स्पॉन_लिंक (मॉड्यूल, फंक्शन, आर्ग्स) -> पिड ()

प्रकार

के अनुप्रयोग द्वारा शुरू की गई एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता को लौटाता Module:Function है Args । कॉलिंग प्रक्रिया और नई प्रक्रिया के बीच, एटोमिक रूप से एक लिंक बनाया जाता है। अन्यथा की तरह काम करता है spawn/3

स्पॉन_लिंक (नोड, मॉड्यूल, फंक्शन, आर्ग्स) -> पिड ()

प्रकार

एक नई प्रक्रिया के प्रोसेस आइडेंटिफ़ायर (pid) Module:Function को Args ऑन करके शुरू की गई एक नई प्रक्रिया का रिटर्न देता है Node । कॉलिंग प्रक्रिया और नई प्रक्रिया के बीच, एटोमिक रूप से एक लिंक बनाया जाता है। यदि Node मौजूद नहीं है, तो एक बेकार पीआईडी ​​वापस आ जाती है और कारण के साथ एक निकास संकेत noconnection कॉलिंग प्रक्रिया को भेजा जाता है। अन्यथा की तरह काम करता है spawn/3

spawn_monitor (मज़ा) -> {pid (), संदर्भ ()}

प्रकार

एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता को लौटाता है, Fun जो रिक्त सूची के अनुप्रयोग द्वारा शुरू होता है [] , और नई प्रक्रिया के लिए बनाए गए मॉनिटर के लिए एक संदर्भ। अन्यथा की तरह काम करता है spawn/3

spawn_monitor (मॉड्यूल, फंक्शन, आर्ग्स) -> {pid (), संदर्भ ()}

प्रकार

के आवेदन के द्वारा एक नई प्रक्रिया शुरू की जाती Module:Function है Args । उसी समय प्रक्रिया की निगरानी की जाती है। मॉनिटर के लिए प्रक्रिया पहचानकर्ता और एक संदर्भ देता है। अन्यथा की तरह काम करता है spawn/3

spawn_opt (मज़ा, विकल्प) -> पिड () | {pid (), संदर्भ ()}

प्रकार

Fun खाली सूची के आवेदन द्वारा शुरू की गई एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता (पीआईडी) लौटाती है [] । अन्यथा की तरह काम करता है spawn_opt/4

यदि विकल्प monitor निर्दिष्ट किया जाता है, तो नई बनाई गई प्रक्रिया की निगरानी की जाती है, और मॉनिटर के लिए पीआईडी ​​और संदर्भ दोनों वापस आ जाते हैं।

spawn_opt (नोड, मज़ा, विकल्प) -> पीआईडी ​​() | {pid (), संदर्भ ()}

प्रकार

के आवेदन के द्वारा शुरू कर दिया एक नई प्रक्रिया की प्रक्रिया पहचानकर्ता (पीआईडी) रिटर्न Fun खाली सूची [] पर Node । यदि Node मौजूद नहीं है, तो एक बेकार पीआईडी ​​वापस आ जाती है। अन्यथा की तरह काम करता है spawn_opt/4

स्पॉन_टॉप (मॉड्यूल, फ़ंक्शन, आर्ग्स, विकल्प) ->
pid () | {pid (), संदर्भ ()}

प्रकार

के रूप में काम करता है spawn/3 , सिवाय इसके कि प्रक्रिया बनाते समय एक अतिरिक्त विकल्प सूची निर्दिष्ट की जाती है।

यदि विकल्प monitor निर्दिष्ट किया जाता है, तो नई बनाई गई प्रक्रिया की निगरानी की जाती है, और मॉनिटर के लिए पीआईडी ​​और संदर्भ दोनों वापस आ जाते हैं।

विकल्प:

link

मूल प्रक्रिया का लिंक सेट spawn_link/3 करता है (जैसे करता है)।

monitor

नई प्रक्रिया को मॉनिटर monitor/2 करता है (जैसे करता है)।

{priority, Level

नई प्रक्रिया की प्राथमिकता तय करता है। process_flag(priority,Level) नई प्रक्रिया के प्रारंभ समारोह में निष्पादित करने के लिए समान है , सिवाय इसके कि पहली बार निष्पादन के लिए प्रक्रिया का चयन करने से पहले प्राथमिकता निर्धारित की जाती है। प्राथमिकताओं के बारे में अधिक जानकारी के लिए, देखें process_flag(priority,Level)

{fullsweep_after, Number}

केवल प्रदर्शन ट्यूनिंग के लिए उपयोगी। इस विकल्प का उपयोग तब तक न करें जब तक आपको पता न हो कि निष्पादन समय या मेमोरी खपत के साथ समस्या है, और सुनिश्चित करें कि विकल्प मामलों में सुधार करता है।

Erlang रनटाइम सिस्टम डेटा के लिए "पुराने ढेर" का उपयोग करते हुए एक पीढ़ीगत कचरा संग्रह योजना का उपयोग करता है, जो कम से कम एक कचरा संग्रह से बच गया है। जब पुराने ढेर पर कोई जगह नहीं है, तो एक फुलस्टेप कचरा संग्रह किया जाता है।

विकल्प fullsweep_after यह सुनिश्चित करता है कि फ़ुलस्विप को मजबूर करने से पहले अधिकतम संग्रह की अधिकतम संख्या को निर्दिष्ट किया जा सके, भले ही पुराने ढेर पर कमरा हो। संख्या को शून्य पर सेट करना सामान्य संग्रह एल्गोरिथ्म को अक्षम करता है, अर्थात, सभी लाइव डेटा को हर कचरा संग्रह में कॉपी किया जाता है।

कुछ मामलों में जब इसे बदलना उपयोगी हो सकता है fullsweep_after :

  • यदि बायनेरिज़ जो अब उपयोग नहीं किए जाते हैं उन्हें जल्द से जल्द फेंक दिया जाना है। ( Number शून्य पर सेट करें ।)

  • एक प्रक्रिया जिसमें ज्यादातर अल्पकालिक डेटा होता है, पूरी तरह से कम या कभी नहीं होता है, यानी पुराने ढेर में ज्यादातर कचरा होता है। कभी-कभी एक फुलस्विप सुनिश्चित करने के लिए, Number एक उपयुक्त मान पर सेट करें, जैसे 10 या 20।

  • एक सीमित मात्रा में रैम और कोई वर्चुअल मेमोरी के साथ एम्बेडेड सिस्टम में, आप Number शून्य पर सेट करके मेमोरी को संरक्षित करना चाह सकते हैं । (मूल्य विश्व स्तर पर सेट किया जा सकता है, देखें erlang:system_flag/2 ।)
{min_heap_size, Size}

केवल प्रदर्शन ट्यूनिंग के लिए उपयोगी। इस विकल्प का उपयोग तब तक न करें जब तक आपको पता न हो कि निष्पादन समय या मेमोरी खपत के साथ समस्या है, और सुनिश्चित करें कि विकल्प मामलों में सुधार करता है।

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

{min_bin_vheap_size, VSize}

केवल प्रदर्शन ट्यूनिंग के लिए उपयोगी। इस विकल्प का उपयोग तब तक न करें जब तक आपको पता न हो कि निष्पादन समय या मेमोरी खपत के साथ समस्या है, और सुनिश्चित करें कि विकल्प मामलों में सुधार करता है।

शब्दों में एक न्यूनतम बाइनरी वर्चुअल हीप आकार देता है। सिस्टम डिफ़ॉल्ट से अधिक यह मान सेट करना कुछ प्रक्रियाओं को गति दे सकता है क्योंकि कम कचरा संग्रह किया जाता है। हालाँकि, बहुत अधिक मान सेट करना स्मृति को बर्बाद कर सकता है। इसलिए, इस विकल्प का उपयोग केवल एक आवेदन को ठीक करने और विभिन्न VSize मूल्यों के साथ निष्पादन के समय को मापने के लिए करें ।

{max_heap_size, Size}

max_heap_size प्रक्रिया ध्वज सेट करता है। डिफ़ॉल्ट max_heap_size कमांड-लाइन तर्क द्वारा निर्धारित किया +hmax जाता है erl(1) । अधिक जानकारी के लिए, का प्रलेखन देखें process_flag(max_heap_size,Size)

{message_queue_data, MQD}

message_queue_data प्रक्रिया ध्वज की स्थिति सेट करता है । MQD या तो होना करने के लिए है off_heap या on_heap । डिफ़ॉल्ट message_queue_data प्रक्रिया ध्वज को कमांड-लाइन तर्क द्वारा निर्धारित किया +hmqd जाता है erl(1) । अधिक जानकारी के लिए, का प्रलेखन देखें process_flag(message_queue_data,MQD)

स्पॉन_टॉप (नोड, मॉड्यूल, फ़ंक्शन, आर्ग्स, विकल्प) ->
pid () | {pid (), संदर्भ ()}

प्रकार

एक नई प्रक्रिया के प्रोसेस आइडेंटिफ़ायर (pid) Module:Function को Args ऑन करके शुरू की गई एक नई प्रक्रिया का रिटर्न देता है Node । यदि Node मौजूद नहीं है, तो एक बेकार पीआईडी ​​वापस आ जाती है। अन्यथा की तरह काम करता है spawn_opt/4

ध्यान दें

विकल्प monitor द्वारा समर्थित नहीं है spawn_opt/5

विभाजित_बिनरी (बिन, स्थिति) -> {बाइनरी (), बाइनरी ()}

प्रकार

0..byte_size (बिन)

द्विपद युक्त एक टपल देता है जो Bin स्थिति में दो भागों में विभाजित होने का परिणाम है Pos । यह एक विनाशकारी ऑपरेशन नहीं है। ऑपरेशन के बाद, पूरी तरह से तीन बायनेरिज़ हैं। उदाहरण:

> B = list_to_binary("0123456789").
<<"0123456789">>
> byte_size(B).
10
> {B1, B2} = split_binary(B,3).
{<<"012">>,<<"3456789">>}
> byte_size(B1).
3
> byte_size(B2).
7
erlang: start_timer (समय, गंतव्य, संदेश) -> टाइमर

प्रकार

एक टाइमर शुरू करता है। बुला के समान erlang:start_timer

erlang: start_timer (समय, गंतव्य, संदेश, विकल्प) -> टाइमर

प्रकार

एक टाइमर शुरू करता है। जब टाइमर समाप्त हो जाता है, तो संदेश {timeout, TimerRef, Msg} द्वारा पहचानी गई प्रक्रिया को भेजा जाता है Dest

Option रों:

{abs, false}

यह डिफ़ॉल्ट है। इसका मतलब है कि Time मान मिलीसेकंड में एक समय के रूप में व्याख्या की है रिश्तेदार वर्तमान Erlang monotonic time

{abs, true}

पूर्ण Time मूल्य। Time मान मिलीसेकंड में एक निरपेक्ष Erlang monotonic समय के रूप में व्याख्या की है।

Option भविष्य में और अधिक जोड़े जा सकते हैं।

समय के पूर्ण बिंदु, टाइमर को समाप्त करने के लिए सेट किया गया है, अंतराल में होना चाहिए [ erlang:system_info(start_time) , erlang:system_info(end_time) ] । यदि एक सापेक्ष समय निर्दिष्ट किया जाता है, तो Time मान को नकारात्मक नहीं होने दिया जाता है।

यदि Dest कोई है pid() , तो यह pid() मौजूदा रनटाइम सिस्टम उदाहरण पर बनाई गई प्रक्रिया का होना चाहिए । इस प्रक्रिया को या तो समाप्त कर दिया गया है या नहीं। तो Dest एक है atom() , यह एक स्थानीय रूप से पंजीकृत प्रक्रिया के नाम के रूप में व्याख्या की है। नाम से संदर्भित प्रक्रिया को टाइमर समाप्ति के समय देखा जाता है। यदि नाम किसी प्रक्रिया को संदर्भित नहीं करता है, तो कोई त्रुटि नहीं दी जाती है।

यदि Dest कोई है pid() , तो टाइमर स्वचालित रूप से रद्द कर दिया जाता pid() है, यदि इसके द्वारा संदर्भित प्रक्रिया जीवित नहीं है, या यदि प्रक्रिया से बाहर निकलता है। यह फीचर ईआरटीएस 5.4.11 में पेश किया गया था। ध्यान दें कि टाइमर स्वचालित रूप से रद्द कर दिया नहीं कर रहे हैं Dest एक है atom()

यह भी देखें erlang:send_after , erlang:cancel_timer/2 , और erlang:read_timer/2

असफलता: badarg यदि तर्क यहाँ निर्दिष्ट आवश्यकताओं को पूरा नहीं करते हैं।

आँकड़े (आइटम :: सक्रिय_कार्य) -> [सक्रिय कार्य]

प्रकार

statistics(active_tasks_all) अपवाद के रूप में उसी के साथ लौटाता है कि गंदे आईओ कतार के बारे में कोई भी जानकारी और उसके संबंधित शेड्यूलर परिणाम का हिस्सा नहीं है। यही है, केवल कार्य जो सीपीयू बाध्य होने की उम्मीद है, परिणाम का हिस्सा हैं।

आँकड़े (आइटम :: active_tasks_all) -> [ActiveTasks]

प्रकार

एक सूची लौटाता है जहां प्रत्येक तत्व सक्रिय प्रक्रियाओं की मात्रा और प्रत्येक रन कतार और उसके संबंधित अनुसूचियों पर बंदरगाहों का प्रतिनिधित्व करता है। यही है, प्रक्रियाओं और बंदरगाहों की संख्या जो चलाने के लिए तैयार हैं, या वर्तमान में चल रहे हैं। सामान्य रन कतारों और उनके संबद्ध अनुसूचियों के मूल्य परिणामी सूची में पहले स्थान पर हैं। पहला तत्व अनुसूचक संख्या 1 और इसी तरह से मेल खाता है। यदि गंदे शेड्यूलर्स के लिए समर्थन मौजूद है, तो गंदे CPU रन कतार के लिए मान वाला एक तत्व और उसके संबंधित गंदे CPU शेड्यूलर अनुसरण करते हैं और फिर अंतिम तत्व के रूप में गंदे IO रन कतार और उसके संबंधित गंदे IO शेड्यूलर का अनुसरण करते हैं। जानकारी को परमाणु से इकट्ठा नहीं किया जाता है । यही है, परिणाम जरूरी नहीं कि राज्य का एक सुसंगत स्नैपशॉट है, बल्कि इसके बजाय काफी कुशलता से इकट्ठा किया गया है।

ध्यान दें

प्रत्येक सामान्य अनुसूचक की एक कतार होती है जिसे वह प्रबंधित करता है। यदि गंदे शेड्यूलर शेड्यूलर्स का समर्थन किया जाता है, तो सभी गंदे CPU शेड्यूलर एक रन कतार साझा करते हैं, और सभी गंदे IO अनुसूचक एक रन कतार साझा करते हैं। यही है, हमारे पास कई सामान्य रन कतारें हैं, एक गंदा CPU रन कतार और एक गंदा IO रन कतार है। विभिन्न प्रकार की रन कतारों के बीच काम नहीं चल सकता है। केवल सामान्य रन कतारों में काम अन्य सामान्य रन कतारों में माइग्रेट कर सकता है। परिणाम का मूल्यांकन करते समय इसे ध्यान में रखा जाना चाहिए।

यह भी देखें statistics(total_active_tasks) , statistics(run_queue_lengths) , statistics(run_queue_lengths_all) , statistics(total_run_queue_lengths) , और statistics(total_run_queue_lengths_all)

आँकड़े (आइटम :: संदर्भ_स्विच) -> {प्रसंगवश, 0}

प्रकार

सिस्टम शुरू होने के बाद से संदर्भ स्विच की कुल संख्या लौटाता है।

आँकड़े (आइटम :: सटीक_पत्र) ->
{Total_Exact_Reductions,
Exact_Reductions_Since_Last_Call}

प्रकार

सटीक कटौती की संख्या लौटाता है।

ध्यान दें

statistics(exact_reductions) से अधिक महंगा ऑपरेशन है statistics(reductions)

आँकड़े (आइटम :: कचरा_करण) ->
{Number_of_GCs, Words_Reclaimed, 0}

प्रकार

उदाहरण के लिए, कचरा संग्रहण के बारे में जानकारी लौटाता है:

> statistics(garbage_collection).
{85,23961,0}

यह जानकारी कुछ कार्यान्वयनों के लिए अमान्य हो सकती है।

आँकड़े (आइटम :: io) -> {{इनपुट, इनपुट}, {आउटपुट, आउटपुट}}

प्रकार

रिटर्न Input , जो बंदरगाहों के माध्यम से प्राप्त बाइट्स की कुल संख्या है, और Output , जो बंदरगाहों के लिए बाइट्स आउटपुट की कुल संख्या है।

आँकड़े (आइटम :: microstate_accounting) ->
[MSAcc_Thread] | अपरिभाषित

प्रकार

माइक्रोस्टेट अकाउंटिंग का उपयोग यह मापने के लिए किया जा सकता है कि एरलांग रनटाइम सिस्टम कितने समय में विभिन्न कार्यों को करने में खर्च करता है। यह संभव के रूप में हल्के होने के लिए डिज़ाइन किया गया है, लेकिन यह सक्षम होने पर कुछ ओवरहेड मौजूद है। Microstate लेखांकन प्रदर्शन बाधाओं को खोजने में मदद करने के लिए एक रूपरेखा उपकरण है। लेखांकन के लिए start / stop / reset microstate, सिस्टम ध्वज का उपयोग करें microstate_accounting

statistics(microstate_accounting) ईआरटीएस के भीतर कुछ ओएस थ्रेड्स का प्रतिनिधित्व करने वाले नक्शे की एक सूची देता है। प्रत्येक नक्शे में शामिल है type और id क्षेत्रों की पहचान करने के लिए क्या धागा यह है इस्तेमाल किया जा सकता, और यह भी एक काउंटर क्षेत्र है कि कितना समय विभिन्न राज्यों में खर्च किया गया है के बारे में डेटा है।

उदाहरण:

> erlang:statistics(microstate_accounting).
[#{counters => #{aux => 1899182914,
                 check_io => 2605863602,
                 emulator => 45731880463,
                 gc => 1512206910,
                 other => 5421338456,
                 port => 221631,
                 sleep => 5150294100},
   id => 1,
   type => scheduler}|...]

टाइम यूनिट वही है जो उसके द्वारा लौटाया गया है os:perf_counter/0 । तो, इसे मिलीसेकंड में बदलने के लिए, आप इस तरह से कुछ कर सकते हैं:

lists:map(
  fun(#{ counters := Cnt } = M) ->
          MsCnt = maps:map(fun(_K, PerfCount) ->
                                   erlang:convert_time_unit(PerfCount, perf_counter, 1000)
                           end, Cnt),
         M#{ counters := MsCnt }
  end, erlang:statistics(microstate_accounting)).

ध्यान दें कि इन मूल्यों की गारंटी नहीं है कि प्रत्येक राज्य में सटीक समय बिताया जाए। इसका कारण ओवरहेड को यथासंभव छोटा रखने के लिए किए गए विभिन्न अनुकूलन हैं।

MSAcc_Thread_Type रों:

scheduler
मुख्य निष्पादन थ्रेड्स जो अधिकांश काम करते हैं। erl +S अधिक जानकारी के लिए देखें।
dirty_cpu_scheduler
लंबे समय तक चलने वाले सीपीयू के गहन कार्य के लिए सूत्र। erl +SDcpu अधिक जानकारी के लिए देखें।
dirty_io_scheduler
लंबे समय तक चलने वाले धागे I / O काम करते हैं। erl +SDio अधिक जानकारी के लिए देखें।
async
Async थ्रेड्स विभिन्न लिंक्ड-इन ड्राइवरों द्वारा उपयोग किए जाते हैं (मुख्य रूप से फ़ाइल ड्राइवर) गैर-सीपीयू गहन कार्य को ऑफलोड करते हैं। erl +A अधिक जानकारी के लिए देखें।
aux
किसी भी काम की देखभाल करता है जो विशेष रूप से एक अनुसूचक को नहीं सौंपा जाता है।
poll
क्या आईओ एमुलेटर के लिए मतदान करता है। erl +IOt अधिक जानकारी के लिए देखें।

निम्नलिखित MSAcc_Thread_State उपलब्ध हैं। सभी राज्य अनन्य हैं, जिसका अर्थ है कि एक धागा एक साथ दो राज्यों में नहीं हो सकता है। इसलिए, यदि आप एक थ्रेड में सभी काउंटरों की संख्या जोड़ते हैं, तो आपको उस थ्रेड के लिए कुल रनटाइम मिलता है।

aux
समय सहायक नौकरियों को संभालने में बिताया।
check_io
नए I / O ईवेंट के लिए समय बिताया।
emulator
एर्लांग प्रक्रियाओं को निष्पादित करने में समय व्यतीत हुआ।
gc
कचरा संग्रह करने में समय व्यतीत होता है। जब अतिरिक्त राज्यों को सक्षम किया जाता है तो यह गैर-फुलस्टेप कचरा संग्रह करने में लगने वाला समय होता है।
other
बेहिसाब बातें करते हुए समय बिताया।
port
समय बंदरगाहों को क्रियान्वित करने में बिताया।
sleep
सोते हुए समय बिताया।

MSAcc_Thread_State कॉन्फ़िगर के माध्यम से अधिक महीन दाने जोड़े जा सकते हैं (जैसे ./configure --with-microstate-accounting=extra )। इन राज्यों को सक्षम करने से प्रदर्शन में गिरावट आती है जब माइक्रोस्टेट लेखांकन बंद हो जाता है और चालू होने पर ओवरहेड बढ़ जाता है।

alloc
स्मृति को बिताते समय। अतिरिक्त राज्यों के बिना यह समय अन्य सभी राज्यों में फैला हुआ है।
bif
बीआईएफएस में समय बिताया। अतिरिक्त राज्यों के बिना यह समय emulator राज्य का हिस्सा है ।
busy_wait
समय व्यस्त प्रतीक्षा में व्यतीत हुआ। यह वह राज्य भी है जहां एक अनुसूचक अब रिपोर्ट नहीं करता है कि यह उपयोग करते समय सक्रिय है statistics(scheduler_wall_time) । इसलिए, यदि आप अन्य सभी राज्यों को जोड़ते हैं, लेकिन यह और सोता है, और फिर उस सभी समय को धागे में विभाजित करते हैं, तो आपको कुछ बहुत समान होना चाहिए scheduler_wall_time । अतिरिक्त राज्यों के बिना यह समय other राज्य का हिस्सा है ।
ets
ETS BIF को निष्पादित करने में समय व्यतीत होता है। अतिरिक्त राज्यों के बिना यह समय emulator राज्य का हिस्सा है ।
gc_full
फुलस्टेप कचरा संग्रह करने में समय व्यतीत होता है। अतिरिक्त राज्यों के बिना यह समय gc राज्य का हिस्सा है ।
nif
एनआईएफ में समय बिताया। अतिरिक्त राज्यों के बिना यह समय emulator राज्य का हिस्सा है ।
send
संदेश भेजने का समय बिताया (केवल प्रक्रियाएं)। अतिरिक्त राज्यों के बिना यह समय emulator राज्य का हिस्सा है ।
timers
समय प्रबंधन का समय बिताया। अतिरिक्त राज्यों के बिना यह समय other राज्य का हिस्सा है ।

यूटिलिटी मॉड्यूल msacc(3) का उपयोग इन आंकड़ों का अधिक आसानी से विश्लेषण करने के लिए किया जा सकता है।

undefined सिस्टम फ्लैग microstate_accounting को बंद कर दिया जाता है, तो लौटाता है।

थ्रेड जानकारी की सूची अनसोल्ड है और कॉल के बीच अलग-अलग क्रम में दिखाई दे सकती है।

ध्यान दें

धागे और राज्य बिना किसी पूर्व सूचना के परिवर्तन के अधीन हैं।

आँकड़े (आइटम :: रिडक्शन) ->
{Total_Reductions, Reductions_Since_Last_Call}

प्रकार

उदाहरण के लिए कटौती के बारे में जानकारी लौटाता है:

> statistics(reductions).
{2046,11}
ध्यान दें

ERTS 5.5 (Erlang / OTP R11B) के रूप में, इस मूल्य में वर्तमान में निर्धारित प्रक्रियाओं के वर्तमान समय के स्लाइस में किए गए कटौती शामिल नहीं हैं। यदि एक सटीक मान चाहिए, तो उपयोग करें statistics(exact_reductions)

आँकड़े (आइटम :: run_queue) -> पूर्णांक ()> = 0

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

आँकड़े (आइटम :: run_queue_lengths) -> [RunQueueLength]

प्रकार

statistics(run_queue_lengths_all) इस अपवाद के साथ ही रिटर्न देता है कि गंदे IO रन कतार के बारे में कोई जानकारी परिणाम का हिस्सा नहीं है। यही है, केवल सीपीयू बाउंड होने की उम्मीद है कि काम के साथ कतारें चलाएं।

आँकड़े (आइटम :: run_queue_lengths_all) -> [RunQueueLength]

प्रकार

एक सूची लौटाता है जहां प्रत्येक तत्व प्रत्येक रन कतार के लिए चलने के लिए तैयार प्रक्रियाओं और बंदरगाहों की मात्रा का प्रतिनिधित्व करता है। सामान्य रन कतारों के लिए परिणाम परिणामी सूची में पहले स्थान पर हैं। पहला तत्व शेड्यूलर नंबर 1 की सामान्य रन कतार और इसी तरह से मेल खाता है। यदि गंदे अनुसूचियों के लिए समर्थन मौजूद है, तो गंदे CPU रन कतार और गंदे IO रन कतार अनुसरण (उस क्रम में) के लिए अंत में मान हैं। जानकारी को परमाणु से इकट्ठा नहीं किया जाता है । यही है, परिणाम जरूरी नहीं कि राज्य का एक सुसंगत स्नैपशॉट है, बल्कि इसके बजाय काफी कुशलता से इकट्ठा किया गया है।

ध्यान दें

प्रत्येक सामान्य अनुसूचक की एक कतार होती है जिसे वह प्रबंधित करता है। यदि गंदे शेड्यूलर शेड्यूलर्स का समर्थन किया जाता है, तो सभी गंदे CPU शेड्यूलर एक रन कतार साझा करते हैं, और सभी गंदे IO अनुसूचक एक रन कतार साझा करते हैं। यही है, हमारे पास कई सामान्य रन कतारें हैं, एक गंदा CPU रन कतार और एक गंदा IO रन कतार है। विभिन्न प्रकार की रन कतारों के बीच काम नहीं चल सकता है। केवल सामान्य रन कतारों में काम अन्य सामान्य रन कतारों में माइग्रेट कर सकता है। परिणाम का मूल्यांकन करते समय इसे ध्यान में रखा जाना चाहिए।

यह भी देखें statistics(run_queue_lengths) , statistics(total_run_queue_lengths_all) , statistics(total_run_queue_lengths) , statistics(active_tasks) , statistics(active_tasks_all) , और statistics(total_active_tasks) , statistics(total_active_tasks_all)

आंकड़े (आइटम :: रनटाइम) ->
{Total_Run_Time, Time_Since_Last_Call}

प्रकार

मिलीसेकंड में, रनटाइम के बारे में जानकारी देता है।

यह एरलांग रनटाइम सिस्टम में सभी थ्रेड्स के लिए रनटाइम का योग है और इसलिए दीवार घड़ी के समय से अधिक हो सकता है।

चेतावनी

यह मान ऑपरेटिंग सिस्टम द्वारा प्रदान की जाने वाली अंतर्निहित कार्यक्षमता में सीमाओं के कारण उपयोग किया जा सकता है।

उदाहरण:

> statistics(runtime).
{1690,1620}
आँकड़े (आइटम ::
अनुसूचक_वॉल_टाइम ) -> [{अनुसूचक, सक्रिय समय, कुल समय}] | अपरिभाषित

प्रकार

के साथ tuples की सूची लौटाता है {SchedulerId, ActiveTime, TotalTime} , जहां SchedulerId अनुसूचक की पूर्णांक आईडी है, ActiveTime वह अवधि है जो अनुसूचक व्यस्त है, और विशिष्ट अनुसूचक के लिए सक्रिय होने के TotalTime बाद की कुल समय अवधि है scheduler_wall_time । ध्यान दें कि सक्रियण समय अनुसूचियों के बीच काफी भिन्न हो सकता है। वर्तमान में गंदे शेड्यूलर सिस्टम शुरू होने पर सक्रिय होते हैं जबकि scheduler_wall_time कार्यक्षमता सक्षम होने के कुछ समय बाद सामान्य शेड्यूल सक्रिय हो जाते हैं । समय इकाई अपरिभाषित है और रिलीज़, OS और सिस्टम पुनरारंभ के बीच परिवर्तन के अधीन हो सकती है। scheduler_wall_time केवल शेड्यूलर उपयोग के लिए सापेक्ष मूल्यों की गणना करने के लिए उपयोग किया जाना है। ActiveTime से अधिक कभी नहीं हो सकता TotalTime

एक व्यस्त अनुसूचक की परिभाषा यह है कि जब यह निष्क्रिय नहीं है और प्रक्रिया (बंदरगाह) का चयन नहीं कर रहा है, तो यह है:

  • निष्पादन प्रक्रिया कोड
  • लिंक्ड-इन ड्राइवर या एनआईएफ कोड को निष्पादित करना
  • BIFs, या किसी अन्य रनटाइम हैंडलिंग को निष्पादित करना
  • कचरा इकट्ठा करना
  • किसी भी अन्य स्मृति प्रबंधन को संभालना

ध्यान दें कि एक अनुसूचक भी व्यस्त हो सकता है, भले ही ओएस ने अनुसूचक धागे को बाहर निकाल दिया हो।

undefined सिस्टम फ्लैग scheduler_wall_time को बंद कर दिया जाता है, तो लौटाता है।

अनुसूचक जानकारी की सूची अनसोल्ड है और कॉल के बीच अलग-अलग क्रम में दिखाई दे सकती है।

ईआरटीएस संस्करण 9.0 के रूप में, गंदे सीपीयू अनुसूचियों को भी परिणाम में शामिल किया जाएगा। यही है, सभी शेड्यूलर थ्रेड्स जो सीपीयू बाउंड काम को संभालने के लिए अपेक्षित हैं। यदि आप भी गंदे I / O अनुसूचियों के बारे में जानकारी चाहते हैं, तो statistics(scheduler_wall_time_all) इसके बजाय उपयोग करें ।

सामान्य अनुसूचियों की श्रेणी में अनुसूचक पहचानकर्ता होंगे 1 =< SchedulerId =< erlang:system_info(schedulers) । डर्टी सीपीयू शेड्यूलर्स में रेंज में अनुसूचक पहचानकर्ता होंगे erlang:system_info(schedulers) < SchedulerId =< erlang:system_info(schedulers) + erlang:system_info(dirty_cpu_schedulers)

ध्यान दें

विभिन्न प्रकार के शेड्यूलर विशिष्ट प्रकार की नौकरियों को संभालते हैं। हर काम एक विशिष्ट अनुसूचक प्रकार को सौंपा जाता है। नौकरियां एक ही प्रकार के विभिन्न शेड्यूलरों के बीच माइग्रेट कर सकती हैं, लेकिन विभिन्न प्रकारों के शेड्यूलरों के बीच कभी नहीं। लौटे परिणाम का मूल्यांकन करते समय इस तथ्य को ध्यान में रखा जाना चाहिए।

का उपयोग करते हुए scheduler_wall_time अनुसूचक उपयोग की गणना करने के:

> erlang:system_flag(scheduler_wall_time, true).
false
> Ts0 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
ok

कुछ समय बाद उपयोगकर्ता एक और स्नैपशॉट लेता है और शेड्यूलर प्रति शेड्यूलर उपयोग की गणना करता है, उदाहरण के लिए:

> Ts1 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
ok
> lists:map(fun({{I, A0, T0}, {I, A1, T1}}) -> {I, (A1 - A0)/(T1 - T0)} end, lists:zip(Ts0,Ts1)).
[{1,0.9743474730177548},
 {2,0.9744843782751444},
 {3,0.9995902361669045},
 {4,0.9738012596572161},
 {5,0.9717956667018103},
 {6,0.9739235846420741},
 {7,0.973237033077876},
 {8,0.9741297293248656}]

कुल शेड्यूलर उपयोग की गणना के लिए समान स्नैपशॉट का उपयोग करना:

> {A, T} = lists:foldl(fun({{_, A0, T0}, {_, A1, T1}}, {Ai,Ti}) -> {Ai + (A1 - A0), Ti + (T1 - T0)} end, {0, 0}, lists:zip(Ts0,Ts1)), TotalSchedulerUtilization = A/T.
0.9769136803764825

कुल अनुसूचक का उपयोग बराबर होगा 1.0 जब सभी मापक दो मापों के बीच हर समय सक्रिय रहते हैं।

एक और (शायद अधिक) उपयोगी मूल्य उपलब्ध सीपीयू समय की अधिकतम राशि के खिलाफ भारित कुल अनुसूचक उपयोग की गणना करना है:

> WeightedSchedulerUtilization = (TotalSchedulerUtilization * (erlang:system_info(schedulers) + erlang:system_info(dirty_cpu_schedulers))) / erlang:system_info(logical_processors_available).
0.9769136803764825

यह भारित शेड्यूलर उपयोग 1.0 तब तक पहुंच जाएगा जब शेड्यूलर अधिकतम उपलब्ध सीपीयू समय के समान समय में सक्रिय होते हैं। यदि उपलब्ध तार्किक प्रोसेसर की तुलना में अधिक अनुसूचक मौजूद हैं, तो यह मान इससे अधिक हो सकता है 1.0

ईआरटीएस संस्करण 9.0 के रूप में, एर्लांग रनटाइम सिस्टम डिफ़ॉल्ट रूप से तार्किक प्रोसेसर की तुलना में अधिक शेड्यूलर होगा। गंदे शेड्यूलर्स के कारण।

ध्यान दें

scheduler_wall_time डिफ़ॉल्ट रूप से अक्षम है। इसे सक्षम करने के लिए, का उपयोग करें erlang:system_flag(scheduler_wall_time, true)

आँकड़े (आइटम ::
अनुसूचक_वॉल_टाइम_आल ) -> [{अनुसूचक, सक्रिय समय, कुल समय}] | अपरिभाषित

प्रकार

इसके statistics(scheduler_wall_time) अलावा, इसके अलावा इसमें सभी गंदे I / O अनुसूचियों की जानकारी भी शामिल है।

गंदे IO अनुसूचियों की श्रेणी में अनुसूचक पहचानकर्ता होंगे erlang:system_info(schedulers) + erlang:system_info(dirty_cpu_schedulers) < SchedulerId =< erlang:system_info(schedulers) + erlang:system_info(dirty_cpu_schedulers) + erlang:system_info(dirty_io_schedulers)

ध्यान दें

ध्यान दें कि गंदे I / O अनुसूचियों पर काम करने वाले से मुख्य रूप से I / O की प्रतीक्षा की जाती है। यही है, जब आप गंदे I / O अनुसूचियों पर उच्च अनुसूचक उपयोग प्राप्त करते हैं, तो इस काम के कारण CPU उपयोग उच्च होने की उम्मीद नहीं है।

आँकड़े (आइटम :: total_active_tasks) -> सक्रिय कार्य

प्रकार

कॉलिंग के समान lists:sum( statistics(active_tasks) ) , लेकिन अधिक कुशल।

आँकड़े (आइटम :: Total_active_tasks_all) -> सक्रिय कार्य

प्रकार

कॉलिंग के समान lists:sum( statistics(active_tasks_all) ) , लेकिन अधिक कुशल।

आँकड़े (आइटम :: Total_run_queue_lengths) ->
TotalRunQueueLengths

प्रकार

कॉलिंग के समान lists:sum( statistics(run_queue_lengths) ) , लेकिन अधिक कुशल।

आँकड़े (आइटम :: Total_run_queue_lengths_all) ->
TotalRunQueueLengths

प्रकार

कॉलिंग के समान lists:sum( statistics(run_queue_lengths_all) ) , लेकिन अधिक कुशल।

आँकड़े (आइटम :: wall_clock) ->
{Total_Wallclock_Time,
Wallclock_Time_Since_Last_Call}

प्रकार

दीवार घड़ी के बारे में जानकारी देता है। wall_clock उसी तरीके से उपयोग किया जा सकता है runtime , जैसे कि वास्तविक समय को रनटाइम या सीपीयू समय के विपरीत मापा जाता है।

एरलैंग: सस्पेंड_प्रोसेस (सस्पेंडी) -> सच

प्रकार

द्वारा पहचानी गई प्रक्रिया को निलंबित करता है Suspendee । बुला के समान erlang:suspend_process/2

चेतावनी

यह बीआईएफ केवल डिबगिंग के लिए है।

एर्लांग: सस्पेंड_प्रोसेस (सस्पेंडी, ऑप्टलिस्ट) -> बूलियन ()

प्रकार

द्वारा पहचानी गई प्रक्रिया पर निलंबित गिनती बढ़ाता है Suspendee और इसे पहले से ही उस स्थिति में नहीं होने पर निलंबित स्थिति में रखता है। एक निलंबित प्रक्रिया निष्पादन के लिए निर्धारित नहीं है जब तक कि प्रक्रिया फिर से शुरू नहीं की गई है।

एक प्रक्रिया को कई प्रक्रियाओं द्वारा निलंबित किया जा सकता है और एक प्रक्रिया द्वारा कई बार निलंबित किया जा सकता है। एक निलंबित प्रक्रिया निलंबित स्थिति को तब तक नहीं छोड़ती है जब तक कि इसकी निलंबित गणना शून्य तक नहीं पहुंच जाती है। Suspendee जब erlang:resume_process(Suspendee) उसी प्रक्रिया से कॉल किया जाता है, तो निलंबित गणना कम हो जाती है erlang:suspend_process(Suspendee) । एक प्रक्रिया द्वारा अधिग्रहित अन्य प्रक्रियाओं पर सभी बढ़े हुए निलंबित मायने रखता है जब प्रक्रिया समाप्त हो जाती है।

विकल्प Opt :

asynchronous

द्वारा निलंबित प्रक्रिया के लिए एक निलंबित अनुरोध भेजा जाता है Suspendee Suspendee अंत में निलंबित कर दिया जाता है जब तक कि इसे फिर से शुरू नहीं किया जा सकता है। erlang:suspend_process/2 चाहे Suspendee अभी तक निलंबित किया गया हो या नहीं , तुरंत रिटर्न का कॉलर । उस समय का समय जब Suspendee सिस्टम में अन्य घटनाओं से निलंबित नहीं किया जा सकता है। यह केवल गारंटी है कि Suspendee अंततः निलंबित (जब तक कि इसे फिर से शुरू नहीं किया जाता है)। कोई तो asynchronous विकल्प पारित किया गया है, के फोन करने वाले erlang:suspend_process/2 जब तक अवरुद्ध है Suspendee निलंबित कर दिया है।

{asynchronous, ReplyTag}

द्वारा निलंबित प्रक्रिया के लिए एक निलंबित अनुरोध भेजा जाता है Suspendee । जब सस्पेंड अनुरोध को संसाधित किया गया है, तो इस फ़ंक्शन के कॉलर को एक उत्तर संदेश भेजा जाता है। उत्तर उस फॉर्म पर है {ReplyTag, State} जहां State या तो है:

exited

Suspendee बाहर निकल गया है।

suspended

Suspendee अब निलंबित कर दिया गया है।

not_suspended

Suspendee निलंबित नहीं किया गया है। यह तभी हो सकता है जब इस अनुरोध को जारी करने वाली प्रक्रिया ने resume_process(Suspendee) जवाब मिलने से पहले फोन किया हो ।

उत्तर संदेश से प्रारंभ करें, {asynchronous, ReplyTag} विकल्प ठीक उसी तरह व्यवहार करता है जैसे asynchronous उत्तर टैग के बिना विकल्प।

unless_suspending

Suspendee तब तक पहचाने जाने वाली प्रक्रिया को निलंबित कर दिया जाता है जब तक कि कॉलिंग प्रक्रिया पहले से ही निलंबित न हो Suspendee । यदि unless_suspending विकल्प के साथ जोड़ दिया जाता है asynchronous , तो एक निलंबित अनुरोध भेजा जाता है जब तक कि कॉलिंग प्रक्रिया पहले से ही निलंबित न हो Suspendee या यदि कोई निलंबित अनुरोध पहले ही भेजा जा चुका हो और पारगमन में हो। यदि कॉलिंग प्रक्रिया पहले से ही सस्पेंड हो रही है Suspendee , या यदि विकल्प के साथ संयुक्त है asynchronous और पहले से ही ट्रांज़िट में भेजा गया अनुरोध false वापस आ गया है, और निलंबित गणना Suspendee अपरिवर्तित बनी हुई है।

यदि द्वारा पहचानी गई प्रक्रिया पर निलंबन की संख्या Suspendee बढ़ जाती है, true तो वापस कर दी जाती है, अन्यथा false

चेतावनी

यह बीआईएफ केवल डिबगिंग के लिए है।

चेतावनी

यदि प्रक्रिया एक-दूसरे (सीधे या मंडलियों) में निलंबित हो जाती है तो आप आसानी से गतिरोध पैदा कर सकते हैं। ईआरटीएस संस्करण 10.0 से पहले ईआरटीएस संस्करणों में, रनटाइम सिस्टम ने इस तरह के गतिरोध को रोका, लेकिन प्रदर्शन कारणों के कारण अब इस रोकथाम को हटा दिया गया है।

विफलताएं:

badarg
यदि Suspendee एक प्रक्रिया पहचानकर्ता नहीं है।
badarg
यदि द्वारा पहचाने जाने Suspendee वाली प्रक्रिया प्रक्रिया कॉलिंग की तरह ही है erlang:suspend_process/2
badarg
यदि पहचान की गई प्रक्रिया Suspendee जीवित नहीं है।
badarg
यदि पहचान की प्रक्रिया Suspendee दूसरे नोड पर रहती है।
badarg
यदि OptList मान्य Opt एस की उचित सूची नहीं है ।
system_limit
यदि Suspendee वर्तमान में उपयोग की गई आंतरिक डेटा संरचनाओं की तुलना में कॉलिंग प्रक्रिया द्वारा पहचान की गई प्रक्रिया को अधिक बार निलंबित कर दिया गया है। सिस्टम की सीमा> 2,000,000,000 सस्पेंड है और यह कभी कम नहीं होगी।
erlang: system_flag (ध्वज :: backtrace_depth, गहराई) -> OldDepth

प्रकार

Tuples के निकास कारण तत्व में कॉल स्टैक बैक-ट्रैक्स की अधिकतम गहराई सेट करता है 'EXIT' । ध्वज process_info आइटम द्वारा लौटाए गए स्टैकट्रेस की गहराई को भी सीमित करता है current_stacktrace.

झंडे का पुराना मूल्य लौटाता है।

erlang: system_flag (ध्वज :: cpu_topology, CpuTopology) ->
OldCpuTopology

प्रकार

चेतावनी

इस तर्क को हटा दिया गया है। इसके बजाय इस तर्क का उपयोग करने के लिए आदेश-पंक्ति तर्क का उपयोग +sct में erl(1)

जब यह तर्क हटा दिया जाता है, तो उपयोग करने के लिए एक अंतिम सीपीयू टोपोलॉजी एमुलेटर बूट समय पर निर्धारित किया जाता है।

उपयोगकर्ता-निर्धारित सेट करता है CpuTopology । उपयोगकर्ता द्वारा परिभाषित सीपीयू टोपोलॉजी किसी भी स्वचालित रूप से पाए गए सीपीयू टोपोलॉजी से आगे निकल जाती है। के undefined रूप में पारित करके CpuTopology , सिस्टम सीपीयू टोपोलॉजी के लिए स्वचालित रूप से पता लगाता है। लौटाया गया मान erlang:system_info(cpu_topology) बदले जाने से पहले दिए गए मान के बराबर होता है।

झंडे का पुराना मूल्य लौटाता है।

सीपीयू टोपोलॉजी का उपयोग तार्किक प्रोसेसर के लिए बाध्यकारी करते समय किया जाता है। यदि CPU टोपोलॉजी बदल जाने पर शेड्यूलर पहले से ही बंधे हैं, तो शेड्यूलर्स को नए CPU मनोविज्ञान के अनुसार रिबंड करने का अनुरोध भेजा जाता है।

उपयोगकर्ता द्वारा परिभाषित CPU टोपोलॉजी को कमांड-लाइन तर्क पास करके भी सेट किया जा सकता +sct है erl(1)

प्रकार CpuTopology और अधिक के बारे में जानकारी के लिए , erlang:system_info(cpu_topology) साथ ही कमांड-लाइन झंडे +sct और +sbt अंदर देखें erl(1)

erlang: system_flag (ध्वज :: गंदे_cpu_schedulers_online,
DirtyCPUSchedulersOnline) ->
OldDirtyCPUSchedulersOnline

प्रकार

गंदे CPU अनुसूचियों की संख्या को ऑनलाइन सेट करता है। रेंज है 1 <= DirtyCPUSchedulersOnline <= N जहां, N की वापसी मान में सबसे छोटी है erlang:system_info(dirty_cpu_schedulers) और erlang:system_info(schedulers_online)

झंडे का पुराना मूल्य लौटाता है।

यदि ऑनलाइन शेड्यूल करने वालों की संख्या में परिवर्तन होता है तो गंदे CPU अनुसूचियों की संख्या ऑनलाइन बदल सकती है। उदाहरण के लिए, यदि 12 अनुसूचकियां और 6 गंदे CPU अनुसूचियां ऑनलाइन हैं, और system_flag/2 इसका उपयोग अनुसूचियों की संख्या को ऑनलाइन 6 पर सेट करने के लिए किया जाता है, तो गंदे CPU अनुसूचियों की ऑनलाइन संख्या स्वचालित रूप से आधे से कम हो जाती है, नीचे 3. तक। गंदे CPU अनुसूचियों की संख्या ऑनलाइन आनुपातिक रूप से बढ़ जाती है, जिससे अनुसूचियों की संख्या ऑनलाइन बढ़ जाती है।

अधिक जानकारी के लिए, देखें erlang:system_info(dirty_cpu_schedulers) और erlang:system_info(dirty_cpu_schedulers_online)

erlang: system_flag (ध्वज :: erts_alloc, मूल्य :: {Alloc, F, V}) ->
ठीक है | notsup

प्रकार

के लिए सिस्टम ध्वज सेट करता है erts_alloc(3) Alloc उदाहरण के लिए, प्रभावित करने वाला आवंटनकर्ता है binary_alloc F बदलने के लिए ध्वज V है और नया मूल्य है।

सभी erts_alloc झंडों का केवल एक सबसेट रन समय पर बदला जा सकता है। यह सबसेट वर्तमान में केवल ध्वज है sbct

ok यदि ध्वज सेट किया गया था या notsup यदि समर्थित नहीं है तो लौटाता है erts_alloc

erlang: system_flag (ध्वज :: fullsweep_after, संख्या) -> OldNumber

प्रकार

सिस्टम ध्वज सेट करता है fullsweep_after Number एक गैर-नकारात्मक पूर्णांक है जो यह दर्शाता है कि फुलस्टेप संग्रह के बिना कितनी बार जेनरल कचरा संग्रह किया जा सकता है। मान नई प्रक्रियाओं पर लागू होता है, जबकि पहले से चल रही प्रक्रियाएं प्रभावित नहीं होती हैं।

झंडे का पुराना मूल्य लौटाता है।

कम-मेमोरी सिस्टम में (विशेषकर वर्चुअल मेमोरी के बिना), मान को सेट 0 करने से मेमोरी को संरक्षित करने में मदद मिल सकती है।

यह मान (OS) परिवेश चर के माध्यम से भी सेट किया जा सकता है ERL_FULLSWEEP_AFTER

erlang: system_flag (ध्वज :: microstate_accounting, Action) ->
OldState

प्रकार

माइक्रोस्टेट लेखांकन माप को चालू / बंद करता है। रीसेट पास करते समय, सभी काउंटर 0 पर रीसेट हो जाते हैं।

अधिक जानकारी के लिए देखते हैं statistics(microstate_accounting)

erlang: system_flag (झंडा :: min_heap_size, MinHeapSize) ->
OldMinHoSize

प्रकार

प्रक्रियाओं के लिए डिफ़ॉल्ट न्यूनतम हीप आकार सेट करता है। आकार शब्दों में निर्दिष्ट है। नया min_heap_size प्रभाव केवल प्रक्रियाओं के परिवर्तन के बाद पैदा हुआ min_heap_size min_heap_size का उपयोग करके spawn_opt/4 या व्यक्तिगत प्रक्रियाओं के लिए सेट किया जा सकता है process_flag/2

झंडे का पुराना मूल्य लौटाता है।

erlang: system_flag (ध्वज :: min_bin_vheap_size, MinBinVHeapSize) ->
OldMinBinVHeapSize

प्रकार

प्रक्रियाओं के लिए डिफ़ॉल्ट न्यूनतम बाइनरी वर्चुअल हीप आकार सेट करता है। आकार शब्दों में निर्दिष्ट है। नया min_bin_vhheap_size प्रभाव केवल प्रक्रियाओं के परिवर्तन के बाद पैदा हुआ min_bin_vheap_size min_bin_vheap_size का उपयोग करके spawn_opt/4 या व्यक्तिगत प्रक्रियाओं के लिए सेट किया जा सकता है process_flag/2

झंडे का पुराना मूल्य लौटाता है।

erlang: system_flag (ध्वज :: max_heap_size, MaxHeapSize) ->
ओल्डमैक्सहाइज़ाइज़

प्रकार

प्रक्रियाओं के लिए डिफ़ॉल्ट अधिकतम ढेर आकार सेटिंग्स सेट करता है। आकार शब्दों में निर्दिष्ट है। नया max_heap_size प्रभाव केवल प्रक्रियाओं में परिवर्तन के बाद पैदा हुआ है। max_heap_size का उपयोग करके spawn_opt/4 या व्यक्तिगत प्रक्रियाओं के लिए सेट किया जा सकता है process_flag(max_heap_size,Size)

झंडे का पुराना मूल्य लौटाता है।

erlang: system_flag (फ्लैग :: मल्टी_स्किल्डिंग, ब्लॉकस्टेट) ->
OldBlockState

प्रकार

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

यदि BlockState =:= block , बहु-समय-निर्धारण अवरुद्ध है। यही है, एक और केवल एक अनुसूचक धागा निष्पादित करेगा। यदि BlockState =:= unblock और कोई भी बहु-शेड्यूलिंग को ब्लॉक नहीं करता है, और यह प्रक्रिया केवल एक बार अवरुद्ध हो गई है, तो बहु-शेड्यूलिंग अनवरोधित हो जाती है।

यदि BlockState =:= block_normal , सामान्य बहु-समय-निर्धारण अवरुद्ध है। यही है, केवल एक सामान्य शेड्यूलर थ्रेड निष्पादित करेगा, लेकिन कई गंदे शेड्यूलर निष्पादित कर सकते हैं। यदि BlockState =:= unblock_normal और कोई भी सामान्य बहु-शेड्यूलिंग को ब्लॉक नहीं करता है, और यह प्रक्रिया केवल एक बार अवरुद्ध हो गई है, तो सामान्य बहु-शेड्यूलिंग को अनवरोधित कर दिया जाता है।

एक प्रक्रिया कई बार मल्टी-शेड्यूलिंग और सामान्य मल्टी-शेड्यूलिंग को ब्लॉक कर सकती है। यदि किसी प्रक्रिया को कई बार अवरुद्ध किया गया है, तो उसे बहु-शेड्यूलिंग ब्लॉक को जारी करने से पहले इसे ठीक से जितनी बार ब्लॉक किया गया है, उतनी बार अनब्लॉक करना होगा। यदि एक प्रक्रिया जिसने मल्टी-शेड्यूलिंग या सामान्य मल्टी-शेड्यूलिंग निकास को अवरुद्ध किया है, तो यह स्वचालित रूप से मल्टी-शेड्यूलिंग और सामान्य मल्टी-शेड्यूलिंग के अपने ब्लॉकिंग को छोड़ देता है।

वापसी मान हैं disabled , blocked , blocked_normal , या enabled । लौटाया गया मान केवल कॉल erlang:system_flag(multi_scheduling, BlockState) किए जाने के बाद स्थिति का वर्णन करता है। वापसी मूल्यों के बारे में जानकारी के लिए, देखें erlang:system_info(multi_scheduling)

ध्यान दें

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

यह भी देखें erlang:system_info(multi_scheduling) , erlang:system_info(normal_multi_scheduling_blockers) , erlang:system_info(multi_scheduling_blockers) , और erlang:system_info(schedulers)

erlang: system_flag (ध्वज :: अनुसूचक_bind_type, कैसे) ->
OldBindType

प्रकार

चेतावनी

इस तर्क को हटा दिया गया है। इसके बजाय इस तर्क का उपयोग करने के लिए आदेश-पंक्ति तर्क का उपयोग +sbt में erl(1) । जब यह तर्क हटा दिया जाता है, तो उपयोग करने के लिए एक अंतिम अनुसूचक बाइंड प्रकार इम्यूलेटर बूट समय पर निर्धारित किया जाता है।

अगर और कैसे शेड्यूलर तार्किक प्रोसेसर के लिए बाध्य हैं, तो नियंत्रण।

जब erlang:system_flag(scheduler_bind_type, How) कहा जाता है, सभी शेड्यूलरों को एक अतुल्यकालिक संकेत ऑनलाइन भेजा जाता है, जिससे उन्हें अनुरोध के अनुसार बाँधने या अनबाइंड करने का प्रयास किया जाता है।

ध्यान दें

यदि कोई अनुसूचक बांधने में विफल रहता है, तो इसे अक्सर चुपचाप नजरअंदाज कर दिया जाता है, क्योंकि वैध तार्किक प्रोसेसर पहचानकर्ताओं को सत्यापित करना हमेशा संभव नहीं होता है। यदि कोई त्रुटि रिपोर्ट की जाती है, तो एक त्रुटि ईवेंट लॉग होता है। यह सत्यापित करने के लिए कि शेड्यूलर्स अनुरोध के अनुसार बाध्य हैं, कॉल करें erlang:system_info(scheduler_bindings)

शेड्यूलर को नए लिनक्स, सोलारिस, फ्रीबीएसडी और विंडोज सिस्टम पर बाध्य किया जा सकता है, लेकिन भविष्य के रिलीज में अधिक सिस्टम का समर्थन किया जाएगा।

शेड्यूलर को बाइंड करने में सक्षम होने के लिए रनटाइम सिस्टम के लिए, सीपीयू टोपोलॉजी को पता होना चाहिए। यदि रनटाइम सिस्टम सीपीयू टोपोलॉजी का स्वचालित रूप से पता लगाने में विफल रहता है, तो इसे परिभाषित किया जा सकता है। सीपीयू टोपोलॉजी को परिभाषित करने के तरीके के बारे में अधिक जानकारी के लिए, कमांड-लाइन फ्लैग +sct इन देखें erl(1)

रनटाइम सिस्टम डिफॉल्ट रूप से शेड्यूलर्स को तार्किक प्रोसेसर से नहीं बांधता है।

ध्यान दें

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

अनुसूचियों को विभिन्न तरीकों से बाध्य किया जा सकता है। तर्क How निर्धारित करता है कि शेड्यूलर कैसे बाध्य हैं और निम्नलिखित में से कोई भी हो सकता है:

unbound
में कमांड लाइन तर्क के रूप +sbt u में ही erl(1)
no_spread
में कमांड लाइन तर्क के रूप +sbt ns में ही erl(1)
thread_spread
में कमांड लाइन तर्क के रूप +sbt ts में ही erl(1)
processor_spread
में कमांड लाइन तर्क के रूप +sbt ps में ही erl(1)
spread
में कमांड लाइन तर्क के रूप +sbt s में ही erl(1)
no_node_thread_spread
में कमांड लाइन तर्क के रूप +sbt nnts में ही erl(1)
no_node_processor_spread
में कमांड लाइन तर्क के रूप +sbt nnps में ही erl(1)
thread_no_node_processor_spread
में कमांड लाइन तर्क के रूप +sbt tnnps में ही erl(1)
default_bind
में कमांड लाइन तर्क के रूप +sbt db में ही erl(1)

How ध्वज scheduler_bind_type को बदले जाने से पहले लौटाया गया मान बराबर होता है ।

विफलताएं:

notsup
यदि अनुसूचियों का बंधन समर्थित नहीं है।
badarg
यदि How प्रलेखित विकल्पों में से एक नहीं है।
badarg
यदि CPU टोपोलॉजी की जानकारी अनुपलब्ध है।

शेड्यूलर बाइंड प्रकार को कमांड-लाइन तर्क पास करके भी सेट किया जा सकता +sbt है erl(1)

अधिक जानकारी के लिए, देखें erlang:system_info(scheduler_bind_type) , erlang:system_info(scheduler_bindings) साथ ही कमांड-लाइन झंडे +sbt और +sct में erl(1)

erlang: system_flag (फ्लैग :: शेड्यूलर_वॉल_टाइम, बूलियन) ->
ओल्डबुलियन

प्रकार

शेड्यूलर वॉल टाइम माप को चालू या बंद करता है।

अधिक जानकारी के लिए, देखें statistics(scheduler_wall_time)

erlang: system_flag (ध्वज :: शेड्यूलर_ऑनलाइन, शेड्यूलरऑनलाइन) ->
OldSchedersersline

प्रकार

अनुसूचियों की संख्या को ऑनलाइन सेट करता है। रेंज है 1 <= SchedulersOnline <= erlang:system_info(schedulers)

झंडे का पुराना मूल्य लौटाता है।

यदि एमुलेटर के लिए समर्थन के साथ बनाया गया था dirty schedulers , तो अनुसूचियों की संख्या को ऑनलाइन बदलकर गंदा सीपीयू अनुसूचियों की संख्या को ऑनलाइन भी बदल सकता है। उदाहरण के लिए, यदि 12 अनुसूचकियां और 6 गंदे CPU अनुसूचियां ऑनलाइन हैं, और system_flag/2 इसका उपयोग अनुसूचियों की संख्या को ऑनलाइन 6 पर सेट करने के लिए किया जाता है, तो गंदे CPU अनुसूचियों की ऑनलाइन संख्या स्वचालित रूप से आधे से कम हो जाती है, नीचे 3. तक। गंदे CPU अनुसूचियों की संख्या ऑनलाइन आनुपातिक रूप से बढ़ जाती है, जिससे अनुसूचियों की संख्या ऑनलाइन बढ़ जाती है।

अधिक जानकारी के लिए, देखें erlang:system_info(schedulers) और erlang:system_info(schedulers_online)

erlang: system_flag (ध्वज :: ट्रेस_कंट्रोल_वर्ड, TCW) -> OldTCW

प्रकार

नोड ट्रेस नियंत्रण शब्द का मान सेट करता है TCW , जो एक अहस्ताक्षरित पूर्णांक होना है। अधिक जानकारी के लिए, set_tcw उपयोगकर्ता के गाइड में "मैच विनिर्देशों एर्लांग में" अनुभाग देखें ।

झंडे का पुराना मूल्य लौटाता है।

erlang: system_flag (ध्वज :: time_offset, मान :: अंतिम रूप) ->
OldState

प्रकार

अंतिम रूप time offset जब single time warp mode प्रयोग किया जाता है। यदि किसी अन्य समय ताना मोड का उपयोग किया जाता है, तो ऑफ़सेट स्थिति को अपरिवर्तित छोड़ दिया जाता है।

पुराने राज्य पहचानकर्ता को लौटाता है, जो है:

  • यदि preliminary लौटाया जाता है, तो अंतिम रूप दिया गया था और समय ऑफसेट अब अंतिम है।

  • यदि final लौटाया जाता है, तो समय की कमी पहले से ही अंतिम स्थिति में थी। यह या तो क्योंकि एक और erlang:system_flag(time_offset, finalize) कॉल या no time warp mode उपयोग किया जाता है।

  • यदि volatile लौटाया जाता है, तो समय ऑफसेट को अंतिम रूप नहीं दिया जा सकता क्योंकि multi-time warp mode इसका उपयोग किया जाता है।

erlang: system_info (आइटम :: अवलोकन) -> बूलियन ()

वर्तमान प्रणाली के बारे में जानकारी देता है। इस फ़ंक्शन के प्रलेखन को निम्न अनुभागों में तोड़ा गया है ताकि इसे नेविगेट करना आसान हो सके।

Memory Allocation

allocated_areas , allocator , alloc_util_allocators , allocator_sizes , elib_malloc

erlang:system_info(cpu_topology)

erlang:system_info(cpu_topology) , logical_processors , update_cpu_info

Process Information

fullsweep_after , garbage_collection , heap_sizes , heap_type , max_heap_size , message_queue_data , min_heap_size , min_bin_vheap_size , procs

System Limits

atom_count , atom_limit , ets_limit , port_count , port_limit , process_count , process_limit

System Time

erlang:system_info(end_time) , os_monotonic_time_source , os_system_time_source , erlang:system_info(start_time) , time_correction , time_offset , time_warp_mode , tolerant_timeofday

Scheduler Information

erlang:system_info(dirty_cpu_schedulers) , erlang:system_info(dirty_cpu_schedulers_online) , erlang:system_info(dirty_io_schedulers) , erlang:system_info(multi_scheduling) , erlang:system_info(multi_scheduling_blockers) , erlang:system_info(normal_multi_scheduling_blockers) , erlang:system_info(scheduler_bind_type) , erlang:system_info(scheduler_bindings) , scheduler_id , erlang:system_info(schedulers) , smp_support , threads , thread_pool_size

Distribution Information

creation , delayed_node_table_gc , dist , dist_buf_busy_limit , dist_ctrl

System Information

build_type , c_compiler_used , check_io , compat_rel , debug_compiled , driver_version , dynamic_trace , dynamic_trace_probes , info , kernel_poll , loaded , machine , modified_timing_level , nif_version , otp_release , port_parallelism , system_version , system_architecture , trace_control_word , version , wordsize

erlang: system_info (मद :: आवंटित_कार्य) -> [टुपल ()]
erlang: system_info (मद :: आवंटनकर्ता) ->
{एलाटेटर, संस्करण, सुविधाएँ, सेटिंग}
erlang: system_info (मद :: {आवंटनकर्ता, Alloc}) -> [अवधि ()]
erlang: system_info (आइटम :: आबंटन_सुविधाएँ) -> [Alloc]
erlang: system_info (आइटम :: {आवंटनकर्ता_आसानी, Alloc}) -> [अवधि ()]
erlang: system_info (आइटम :: elib_malloc) -> गलत

प्रकार

वर्तमान प्रणाली (एमुलेटर) के मेमोरी एलोकेटर्स के बारे में विभिन्न जानकारी देता है Item :

allocated_areas

विविध आवंटित स्मृति क्षेत्रों के बारे में जानकारी के साथ ट्यूपल्स की सूची लौटाता है।

प्रत्येक टपल में एक परमाणु होता है जो पहले तत्व के रूप में मेमोरी के प्रकार और बाइट्स में आवंटित मेमोरी की मात्रा को दूसरे तत्व के रूप में वर्णित करता है। जब आवंटित और उपयोग की गई मेमोरी के बारे में जानकारी मौजूद है, तो एक तीसरा तत्व भी मौजूद है, जिसमें बाइट्स में इस्तेमाल की गई मेमोरी की मात्रा है।

erlang:system_info(allocated_areas) डिबगिंग के लिए इरादा है, और सामग्री अत्यधिक कार्यान्वयन-निर्भर है। परिणामों की सामग्री इसलिए पूर्व सूचना के बिना आवश्यक होने पर बदल जाती है।

ध्यान दें कि इन मानों का योग एमुलेटर द्वारा आवंटित स्मृति की कुल राशि नहीं है। कुछ मान अन्य मानों का हिस्सा हैं, और कुछ स्मृति क्षेत्र परिणाम का हिस्सा नहीं हैं। एमुलेटर द्वारा आवंटित स्मृति की कुल मात्रा के बारे में जानकारी के लिए, देखें erlang:memory/0

allocator

रिटर्न {Allocator, Version, Features, Settings , जहां:

  • Allocator malloc() उपयोग किए गए कार्यान्वयन से मेल खाती है । यदि Allocator समान है undefined , तो malloc() उपयोग किए गए कार्यान्वयन की पहचान नहीं की जा सकती है। glibc पहचाना जा सकता है।

  • Version malloc() उपयोग किए गए कार्यान्वयन के संस्करण का प्रतिनिधित्व करने वाले पूर्णांक (लेकिन एक स्ट्रिंग नहीं) की एक सूची है ।

  • Features उपयोग की जाने वाली आवंटन सुविधाओं का प्रतिनिधित्व करने वाले परमाणुओं की एक सूची है।

  • Settings उप-प्रणालियों की सूची, उनके विन्यास योग्य पैरामीटर और उपयोग किए गए मान हैं। प्लेटफार्मों, आवंटनकर्ताओं और आवंटन सुविधाओं के विभिन्न संयोजनों के बीच सेटिंग्स अलग-अलग हो सकती हैं। मेमोरी साइज बाइट्स में दिए गए हैं।

"सिस्टम फ्लैग इफ़ेक्टिंग erts_alloc" भी देखें erts_alloc(3)

{allocator, Alloc}

निर्दिष्ट आवंटनकर्ता के बारे में जानकारी देता है। ईआरटीएस 5.6.1 के रूप में, वापसी मूल्य {instance, InstanceNo, InstanceInfo} ट्यूपल्स की एक सूची है , InstanceInfo जिसमें आवंटन के एक विशिष्ट उदाहरण के बारे में जानकारी शामिल है। यदि Alloc कोई मान्यता प्राप्त आवंटनकर्ता नहीं है, तो undefined उसे लौटा दिया जाता है। यदि Alloc अक्षम किया गया है, false तो वापस कर दिया जाता है।

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

मान्यता प्राप्त आवंटनकर्ताओं में सूचीबद्ध हैं erts_alloc(3) । सुपर कैरियर्स के बारे में जानकारी {allocator, erts_mmap} ईआरटीएस 8.0 से या ईआरटीएस 5.10.4 से प्राप्त की जा सकती है ; लौटी हुई सूची के साथ कॉल करने पर सूची में एक तत्व के रूप {allocator, mseg_alloc} में एक {erts_mmap, _} टपल भी शामिल है ।

erts_alloc(3) दस्तावेज़ीकरण पढ़ने के बाद , लौटी जानकारी कम या ज्यादा अपने लिए बोलती है, लेकिन यह कुछ चीजों को समझाने के लायक हो सकती है। कॉल काउंट दो मूल्यों द्वारा प्रस्तुत किए जाते हैं, पहला मूल्य गीगा कॉल है, और दूसरा मूल्य कॉल है। mbcs और sbcs क्रमशः बहु-ब्लॉक वाहक और एकल-ब्लॉक वाहक को निरूपित करें। आकार बाइट्स में प्रस्तुत किए जाते हैं। जब एक आकार प्रस्तुत नहीं किया जाता है, तो यह किसी चीज़ की मात्रा होती है। आकारों और राशियों को अक्सर तीन मूल्यों द्वारा प्रस्तुत किया जाता है:

  • पहला वर्तमान मूल्य है।
  • आखिरी कॉल के बाद से दूसरा अधिकतम मूल्य है erlang:system_info({allocator, Alloc})
  • एमुलेटर शुरू होने के बाद से तीसरा अधिकतम मूल्य है।

यदि केवल एक मान मौजूद है, तो यह वर्तमान मान है। fix_alloc मेमोरी ब्लॉक प्रकार दो मानों द्वारा प्रस्तुत किए जाते हैं। पहला मान मेमोरी पूल आकार और दूसरा मान उपयोग की गई मेमोरी का आकार है।

alloc_util_allocators

ईआरटीएस आंतरिक alloc_util ढांचे का उपयोग परमाणुओं के रूप में सभी आवंटनकर्ताओं के नामों की सूची देता है । अधिक जानकारी के लिए खंड देखें The alloc_util framework में erts_alloc(3)

{allocator_sizes, Alloc}

निर्दिष्ट आबंटक के लिए विभिन्न आकार की जानकारी देता है। लौटाई गई जानकारी, द्वारा दी गई जानकारी का एक सबसेट है erlang:system_info({allocator,Alloc})

elib_malloc

भविष्य के रिलीज़ में इस विकल्प को हटा दिया जाएगा। वापसी मूल्य हमेशा रहेगा false , क्योंकि elib_malloc आवंटनकर्ता को हटा दिया गया है।

erlang: system_info (आइटम :: cpu_topology) -> CUPTopology
erlang: system_info (आइटम ::
{cpu_topology, परिभाषित | पता लगाया गया | उपयोग किया गया}) ->
CpuTology
erlang: system_info (आइटम ::
तार्किक_प्रोसेसर |
तार्किक_प्रोसेसर_अभिभूत |
तार्किक_प्रोसेसर_ऑनलाइन) ->
अज्ञात पूर्णांक ()> = 1
erlang: system_info (आइटम :: update_cpu_info) -> परिवर्तित | स्थिर

प्रकार

LevelEntry सूची में सभी को समान होना चाहिए LevelTag , शीर्ष स्तर को छोड़कर जहां दोनों node और processor LevelTag सह-अस्तित्व हो सकता है। भविष्य के रिलीज़ में {LevelTag, SubLevel} == {LevelTag, [], SubLevel} और अधिक LevelTag प्रस्तुत किए जा सकते हैं। info_list() एक भविष्य के रिलीज में बढ़ाया जा सकता है।

वर्तमान प्रणाली (एमुलेटर) के सीपीयू टोपोलॉजी के बारे में विभिन्न जानकारी देता है Item :

cpu_topology

CpuTopology वर्तमान में एमुलेटर द्वारा उपयोग किए जाने वाले रिटर्न । सीपीयू टोपोलॉजी का उपयोग तार्किक प्रोसेसर के लिए बाध्यकारी करते समय किया जाता है। सीपीयू टोपोलॉजी का उपयोग किया जाता है user-defined CPU topology , यदि ऐसा मौजूद है, अन्यथा automatically detected CPU topology , यदि ऐसा मौजूद है। यदि कोई CPU टोपोलॉजी मौजूद नहीं है, undefined तो लौटा दिया जाता है।

node गैर-वर्दी मेमोरी एक्सेस (NUMA) नोड्स को संदर्भित करता है। thread हार्डवेयर थ्रेड्स को संदर्भित करता है (उदाहरण के लिए, इंटेल हाइपर-थ्रेड्स)।

CpuTopology यदि केवल एक प्रविष्टि मौजूद है और InfoList खाली है तो टर्म में एक स्तर छोड़ा जा सकता है ।

thread केवल एक उपशीर्षक हो सकता है core । या के core लिए एक उपशीर्षक हो सकता है । शीर्ष स्तर या करने के लिए एक उपरिशायी हो सकता है । शीर्ष स्तर या करने के लिए एक उपरिशायी हो सकता है । यही है, एनयूएमए नोड प्रोसेसर आंतरिक या प्रोसेसर बाहरी हो सकता है। एक सीपीयू टोपोलॉजी में प्रोसेसर आंतरिक और बाहरी NUMA नोड्स का मिश्रण हो सकता है, जब तक कि प्रत्येक तार्किक CPU एक NUMM नोड से संबंधित हो। कैश पदानुक्रम प्रकार का हिस्सा नहीं है , लेकिन भविष्य के रिलीज में होगा। अन्य चीजें भविष्य के रिलीज में इसे सीपीयू टोपोलॉजी में भी बना सकती हैं। इसलिए, प्रकार बदलने की अपेक्षा करें । processor node processor node node processor CpuTopology CpuTopology

{cpu_topology, defined}

उपयोगकर्ता-परिभाषित लौटाता है CpuTopology । अधिक जानकारी के लिए, कमांड-लाइन फ्लैग +sct इन erl(1) और तर्क देखें erlang:system_info(cpu_topology)

{cpu_topology, detected}

स्वचालित रूप से पता लगाता है CpuTopologyy । एमुलेटर कुछ नए लिनक्स, सोलारिस, फ्रीबीएसडी और विंडोज सिस्टम पर सीपीयू टोपोलॉजी का पता लगाता है। 32 से अधिक तार्किक प्रोसेसर वाले विंडोज सिस्टम पर, सीपीयू टोपोलॉजी का पता नहीं लगाया गया है।

अधिक जानकारी के लिए, तर्क देखें erlang:system_info(cpu_topology)

{cpu_topology, used}

CpuTopology एमुलेटर द्वारा उपयोग किए जाने वाले रिटर्न । अधिक जानकारी के लिए, तर्क देखें erlang:system_info(cpu_topology)

logical_processors

सिस्टम में कॉन्फ़िगर किए गए तार्किक प्रोसेसर की ज्ञात संख्या लौटाता है। वापसी मान या तो एक पूर्णांक है, या परमाणु unknown यदि एमुलेटर कॉन्फ़िगर किए गए तार्किक प्रोसेसर का पता नहीं लगा सकता है।

logical_processors_available

Erlang रनटाइम सिस्टम के लिए उपलब्ध तार्किक प्रोसेसर की ज्ञात संख्या लौटाता है। unknown यदि एम्यूलेटर उपलब्ध तार्किक प्रोसेसर का पता नहीं लगा सकता है तो रिटर्न वैल्यू या तो पूर्णांक या परमाणु है । उपलब्ध तार्किक प्रोसेसर की संख्या, की संख्या से कम या उसके बराबर है logical processors online

logical_processors_online

सिस्टम पर ऑनलाइन लॉजिकल प्रोसेसर की संख्या का पता लगाता है। unknown यदि एम्यूलेटर तार्किक प्रोसेसर का ऑनलाइन पता नहीं लगा सकता है तो रिटर्न वैल्यू या तो पूर्णांक या परमाणु है । ऑनलाइन तार्किक प्रोसेसर की संख्या की संख्या से कम या उसके बराबर है logical_processors

update_cpu_info

क्रम प्रणाली उपलब्ध सीपीयू जानकारी rereads और के बारे में अपने आंतरिक रूप से संग्रहीत जानकारी अद्यतन करता है detected CPU topology और तार्किक प्रोसेसर की संख्या logical_processors , online , और available

यदि पिछली बार पढ़ने के बाद से सीपीयू जानकारी बदल गई है, तो परमाणु changed वापस आ गया है, अन्यथा परमाणु unchanged । यदि सीपीयू जानकारी बदल गई है, तो आप शायद चाहते हैं adjust the number of schedulers online । आप आमतौर पर ऑनलाइन के रूप में कई अनुसूचियां रखना चाहते हैं available

erlang: system_info (आइटम :: fullsweep_after) ->
{fullsweep_after, पूर्णांक ()> = 0}
erlang: system_info (आइटम :: कचरा_ रंगकरण) ->
[{परमाणु (), पूर्णांक ()}]
erlang: system_info (आइटम :: heap_sizes) -> [पूर्णांक ()> = 0]
erlang: system_info (आइटम :: heap_type) -> निजी
erlang: system_info (आइटम :: max_heap_size) ->
{max_heap_size,
MaxHeapSize :: max_heap_size ()}
erlang: system_info (आइटम :: message_queue_data) ->
message_queue_data()
erlang: system_info (आइटम :: min_heap_size) ->
{min_heap_size,
MinHeapSize :: पूर्णांक ()> = 1}
erlang: system_info (आइटम :: min_bin_vheap_size) ->
{min_bin_vheap_size,
MinBinVHeapSize :: पूर्णांक ()> = 1}
erlang: system_info (आइटम :: सहारा) -> बाइनरी ()

प्रकार

डिफ़ॉल्ट प्रक्रिया हीप सेटिंग्स के बारे में जानकारी लौटाता है:

fullsweep_after

रिटर्न {fullsweep_after, integer() >= 0} , जो कि fullsweep_after गारबेज कलेक्शन सेटिंग है, जिसका उपयोग डिफ़ॉल्ट रूप से किया जाता है। अधिक जानकारी के लिए, garbage_collection नीचे वर्णित देखें।

garbage_collection

डिफ़ॉल्ट कचरा संग्रह सेटिंग का वर्णन करने वाली सूची लौटाता है। एक प्रक्रिया एक से स्थानीय नोड पर पैदा की spawn या spawn_link इन कचरा संग्रहण सेटिंग्स का उपयोग करता। डिफ़ॉल्ट सेटिंग्स का उपयोग करके बदला जा सकता है erlang:system_flag/2 spawn_opt/4 डिफ़ॉल्ट सेटिंग्स का उपयोग नहीं करने वाली प्रक्रिया को स्पॉन कर सकता है।

heap_sizes

शब्दों में मान्य हीप आकारों का प्रतिनिधित्व करने वाले पूर्णांकों की सूची लौटाता है। इस सूची में सभी एरलंग ढेर आकार से आकार के हैं।

heap_type

वर्तमान एमुलेटर द्वारा उपयोग किए गए ढेर प्रकार को वापस करता है। एक हीप प्रकार मौजूद है:

private
प्रत्येक प्रक्रिया में इसके उपयोग के लिए आरक्षित ढेर होता है और विभिन्न प्रक्रियाओं के ढेर के बीच कोई संदर्भ नहीं होता है। प्रक्रियाओं के बीच पारित संदेशों को ढेर के बीच कॉपी किया जाता है।
max_heap_size

रिटर्न {max_heap_size, MaxHeapSize} , जहां MaxHeapSize मौजूदा सिस्टम-वाइड अधिकतम हीप आकार सेटिंग्स स्पॉन्ड प्रक्रियाओं के लिए है। यह सेटिंग कमांड-लाइन झंडे का उपयोग करके सेट की जा सकती है +hmax , +hmaxk और +hmaxel अंदर erl(1) । इसे रनटाइम का उपयोग करके भी बदला जा सकता है erlang:system_flag(max_heap_size, MaxHeapSize) max_heap_size प्रक्रिया ध्वज के बारे में अधिक जानकारी के लिए , देखें process_flag(max_heap_size,Size)

message_queue_data

message_queue_data प्रक्रिया ध्वज के डिफ़ॉल्ट मान लौटाता है , जो off_heap या तो है on_heap । यह डिफ़ॉल्ट कमांड-लाइन तर्क द्वारा सेट किया +hmqd गया है erl(1) message_queue_data प्रक्रिया ध्वज के बारे में अधिक जानकारी के लिए , का प्रलेखन देखें process_flag(message_queue_data, MQD)

min_heap_size

रिटर्न {min_heap_size, MinHeapSize} , जहां MinHeapSize मौजूदा सिस्टम-वाइड न्यूनतम हीप आकार है जो स्पैन्ड प्रक्रियाओं के लिए है।

min_bin_vheap_size

रिटर्न {min_bin_vheap_size, MinBinVHeapSize} , जहां MinBinVHeapSize मौजूदा सिस्टम-वाइड न्यूनतम द्विआधारी वर्चुअल हीप आकार है जो स्पैन्ड प्रक्रियाओं के लिए है।

procs

एक द्विआधारी देता है जिसमें प्रक्रिया की एक स्ट्रिंग होती है और इरलांग क्रैश डंप में पोर्ट की गई जानकारी स्वरूपित होती है। अधिक जानकारी के लिए, How to interpret the Erlang crash dumps उपयोगकर्ता मार्गदर्शिका में अनुभाग देखें ।

erlang: system_info (आइटम :: atom_count) -> पूर्णांक ()> = 1
erlang: system_info (आइटम :: atom_limit) -> पूर्णांक ()> = 1
erlang: system_info (आइटम :: ets_limit) -> पूर्णांक ()> = 1
erlang: system_info (आइटम :: port_count) -> पूर्णांक ()> = 0
erlang: system_info (आइटम :: port_limit) -> पूर्णांक ()> = 1
erlang: system_info (आइटम :: process_count) -> पूर्णांक ()> = 1
erlang: system_info (आइटम :: process_limit) -> पूर्णांक ()> = 1

वर्तमान प्रणाली (एमुलेटर) सीमा के बारे में जानकारी निम्नानुसार देता है Item :

atom_count

वर्तमान में स्थानीय नोड पर मौजूद परमाणुओं की संख्या लौटाता है। मान एक पूर्णांक के रूप में दिया जाता है।

atom_limit

अनुमत परमाणुओं की अधिकतम संख्या देता है। कमांड-लाइन फ़्लैग +t को पास करके स्टार्टअप में इस सीमा को बढ़ाया जा सकता है erl(1)

ets_count

वर्तमान में स्थानीय नोड पर मौजूद ETS तालिकाओं की संख्या लौटाता है।

ets_limit

ईटीएस तालिकाओं की संख्या के लिए सीमा लौटाता है। यह सीमा है partially obsolete और तालिकाओं की संख्या केवल उपलब्ध स्मृति द्वारा सीमित है।

port_count

वर्तमान में स्थानीय नोड पर मौजूद पोर्ट की संख्या लौटाता है। मान एक पूर्णांक के रूप में दिया जाता है। यह उसी मान के रूप में है जो लौटा है length(erlang:ports()) , लेकिन अधिक कुशल है।

port_limit

पूर्णांक के रूप में स्थानीय नोड पर एक साथ मौजूदा पोर्ट की अधिकतम संख्या देता है। इस सीमा को स्टार्टअप में कमांड-लाइन फ़्लैग का उपयोग करके कॉन्फ़िगर किया जा सकता +Q है erl(1)

process_count

वर्तमान में स्थानीय नोड पर मौजूद प्रक्रियाओं की संख्या लौटाता है। मान एक पूर्णांक के रूप में दिया जाता है। यह उसी मान के रूप में है जो लौटा है length(processes()) , लेकिन अधिक कुशल है।

process_limit

स्थानीय नोड पर एक साथ मौजूदा प्रक्रियाओं की अधिकतम संख्या लौटाता है। मान एक पूर्णांक के रूप में दिया जाता है। इस सीमा को स्टार्टअप में कमांड-लाइन फ़्लैग का उपयोग करके कॉन्फ़िगर किया जा सकता +P है erl(1)

erlang: system_info (आइटम :: end_time) -> पूर्णांक ()> = 0
erlang: system_info (आइटम :: os_monotonic_time_source) ->
[{atom (), term ()}]
erlang: system_info (आइटम :: os_system_time_source) ->
[{atom (), term ()}]
erlang: system_info (आइटम :: start_time) -> पूर्णांक ()
erlang: system_info (आइटम :: time_correction) -> सच | असत्य
erlang: system_info (आइटम :: time_offset) ->
प्रारंभिक | फाइनल | परिवर्तनशील
erlang: system_info (आइटम :: time_warp_mode) ->
no_time_warp |
single_time_warp |
multi_time_warp
erlang: system_info (मद :: सहिष्णु_समय) ->
सक्षम | विकलांग

वर्तमान प्रणाली (एमुलेटर) के समय के बारे में जानकारी निर्दिष्ट के अनुसार देता है Item :

end_time

पिछले erlang:monotonic_time() में native time_unit() है कि मौजूदा Erlang क्रम प्रणाली उदाहरण में आंतरिक रूप से दर्शाया जा सकता है। erlang:system_info(start_time) अंत समय के बीच का समय कम से कम एक चौथाई सहस्राब्दी का होता है।

os_monotonic_time_source

उस सूची को लौटाता है जिसके स्रोत के बारे में जानकारी OS monotonic time रनटाइम सिस्टम द्वारा उपयोग की जाती है।

यदि [] लौटाया जाता है, तो कोई ओएस मोनोटोनिक समय उपलब्ध नहीं होता है। सूची में Key पहले तत्व के रूप में एस के साथ दो-ट्यूपल हैं , और Value दूसरे तत्व के रूप में एस। इन टुपल्स का क्रम अपरिभाषित है। निम्नलिखित ट्यूपल्स सूची का हिस्सा हो सकते हैं, लेकिन भविष्य में और अधिक ट्यूपल पेश किए जा सकते हैं:

{function, Function}

Function उपयोग किए गए फ़ंक्शन का नाम है। यदि ओएस मोनोटोनिक समय रनटाइम सिस्टम के लिए उपलब्ध है तो यह टपल हमेशा मौजूद रहता है।

{clock_id, ClockId}

यह टपल केवल तभी मौजूद होता है जब Function इसका उपयोग विभिन्न घड़ियों के साथ किया जा सकता है। ClockId कॉल करते समय उपयोग किए गए घड़ी पहचानकर्ता से मेल खाती है Function

{resolution, OsMonotonicTimeResolution}

resolution वर्तमान ओएस मोनोटोनिक समय स्रोत के उच्चतम संभव प्रति सेकंड भागों के रूप में। यदि कोई रिज़ॉल्यूशन जानकारी OS से पुनर्प्राप्त नहीं की जा सकती है, तो OsMonotonicTimeResolution वह Function s रिटर्न वैल्यू के टाइम यूनिट के रिज़ॉल्यूशन पर सेट है । यानी वास्तविक रिज़ॉल्यूशन इससे कम हो सकता है OsMonotonicTimeResolution । ध्यान दें कि रिज़ॉल्यूशन के साथ संरेखण के बारे में कुछ भी नहीं कहा गया है accuracy या नहीं precision । हालाँकि, आप जानते हैं कि परिशुद्धता इससे बेहतर नहीं है OsMonotonicTimeResolution

{extended, Extended}

Extended समतुल्य है yes यदि समय मानों की सीमा बढ़ा दी गई है; नहीं के Extended बराबर है no । सीमा को बढ़ाया जाना चाहिए यदि Function रिटर्न तेजी से लिपटे मूल्यों को वापस करता है। यह आमतौर पर तब होता है जब रिटर्न वैल्यू 32-बिट वैल्यू होती है।

{parallel, Parallel}

Parallel बराबरी yes अगर Function कई धागे से समानांतर में कहा जाता है। यदि इसे समानांतर में नहीं कहा जाता है, क्योंकि कॉल को क्रमबद्ध, Parallel बराबर होना चाहिए no

{time, OsMonotonicTime}

OsMonotonicTime में वर्तमान ओएस मोनोटोनिक समय के बराबर है native time_unit()

os_system_time_source

उस सूची को लौटाता है जिसके स्रोत के बारे में जानकारी OS system time रनटाइम सिस्टम द्वारा उपयोग की जाती है।

सूची में Key पहले तत्व के रूप में एस के साथ दो-ट्यूपल हैं , और Value दूसरे तत्व के रूप में एस। इन टुपल्स के अपरिभाषित होने पर क्रम। निम्नलिखित ट्यूपल्स सूची का हिस्सा हो सकते हैं, लेकिन भविष्य में और अधिक ट्यूपल पेश किए जा सकते हैं:

{function, Function}

Function उपयोग की गई फफूंद का नाम है।

{clock_id, ClockId}

केवल तभी होता है जब Function विभिन्न घड़ियों के साथ उपयोग किया जा सकता है। ClockId कॉल करते समय उपयोग किए गए घड़ी पहचानकर्ता से मेल खाती है Function

{resolution, OsSystemTimeResolution}

resolution वर्तमान OS सिस्टम समय स्रोत के प्रति सेकंड के रूप में उच्चतम संभव । यदि कोई रिज़ॉल्यूशन जानकारी OS से पुनर्प्राप्त नहीं की जा सकती है, तो OsSystemTimeResolution वह Function s रिटर्न वैल्यू के टाइम यूनिट के रिज़ॉल्यूशन पर सेट है । यानी वास्तविक रिज़ॉल्यूशन इससे कम हो सकता है OsSystemTimeResolution । ध्यान दें कि रिज़ॉल्यूशन के बारे में कुछ भी नहीं कहता है accuracy या क्या precision रिज़ॉल्यूशन के साथ संरेखित करते हैं। हालाँकि, आप जानते हैं कि परिशुद्धता इससे बेहतर नहीं है OsSystemTimeResolution

{parallel, Parallel}

Parallel बराबरी yes अगर Function कई धागे से समानांतर में कहा जाता है। यदि इसे समानांतर में नहीं कहा जाता है, क्योंकि कॉल को क्रमबद्ध, Parallel समान होने की आवश्यकता है no

{time, OsSystemTime}

OsSystemTime वर्तमान OS सिस्टम समय के बराबर है native time_unit()

start_time

erlang:monotonic_time() में native time_unit() समय में जब वर्तमान Erlang क्रम प्रणाली उदाहरण शुरू कर दिया।

यह भी देखें erlang:system_info(end_time)

time_correction

time correction सक्षम होने या न होने का संकेत देने वाला बूलियन मान लौटाता है ।

time_offset

ऑफ़सेट समय की स्थिति देता है:

preliminary

समय ऑफसेट प्रारंभिक है, और बाद में बदल दिया जाएगा और अंतिम रूप दिया जाएगा। प्रारंभिक समय ऑफसेट का उपयोग प्रारंभिक चरण के दौरान किया जाता है single time warp mode

final

समय ऑफसेट अंतिम है। यह या तो क्योंकि no time warp mode उपयोग किया जाता है, या क्योंकि समय ऑफसेट को अंतिम रूप दिया गया है जब single time warp mode इसका उपयोग किया जाता है।

volatile

समय ऑफसेट अस्थिर है। यानी यह किसी भी समय बदल सकता है। ऐसा इसलिए है क्योंकि multi-time warp mode इसका उपयोग किया जाता है।

time_warp_mode

उस मूल्य की पहचान करता time warp mode है जिसका उपयोग किया जाता है:

no_time_warp
no time warp mode प्रयोग किया जाता है।
single_time_warp
single time warp mode प्रयोग किया जाता है।
multi_time_warp
multi-time warp mode प्रयोग किया जाता है।
tolerant_timeofday

लौटाता है कि सिस्टम समय के अचानक परिवर्तन के लिए एक पूर्व ईआरटीएस 7.0 पीछे संगत मुआवजा है enabled या नहीं disabled । इस तरह का मुआवजा enabled जब time_offset है final , और time_correction सक्षम है।

erlang: system_info (आइटम :: गंदे_cpu_schedulers) ->
पूर्णांक ()> = 0
erlang: system_info (आइटम :: गंदे_cpu_schedulers_online) ->
पूर्णांक ()> 0
erlang: system_info (आइटम :: गंदे_io_schedulers) ->
पूर्णांक ()> = 0
erlang: system_info (आइटम :: multi_scheduling) ->
अक्षम |
अवरुद्ध |
block_normal |
सक्षम
erlang: system_info (आइटम :: multi_scheduling_blockers) ->
[Pid :: pid ()]
erlang: system_info (आइटम :: normal_multi_scheduling_blockers) ->
[Pid :: pid ()]
erlang: system_info (आइटम :: अनुसूचक_बिंद_टाइप) ->
प्रसार |
प्रोसेसर_स्प्रेड |
थ्रेड_स्प्रेड |
थ्रेड_नो_नोड_प्रोसेसर_स्प्रेड |
no_node_processor_spread |
no_node_thread_spread |
no_spread |
अबाध
erlang: system_info (आइटम :: शेड्यूलर_बिन्डिंग) -> tuple ()
erlang: system_info (आइटम :: अनुसूचक_id) ->
समयबद्धक :: पूर्णांक ()> = 1
erlang: system_info (आइटम :: शेड्यूलर्स | शेड्यूलर्स_ऑनलाइन) ->
पूर्णांक ()> = 1
erlang: system_info (आइटम :: smp_support) -> बूलियन ()
erlang: system_info (आइटम :: थ्रेड्स) -> बूलियन ()
erlang: system_info (आइटम :: थ्रेड_पुल_साइज़) -> पूर्णांक ()> = 0

वर्तमान प्रणाली के अनुसार शेड्यूलर्स, शेड्यूलिंग और थ्रेड्स की जानकारी देता है Item :

dirty_cpu_schedulers

एमुलेटर द्वारा उपयोग किए जाने वाले गंदे CPU शेड्यूलर थ्रेड्स की संख्या लौटाता है। डर्टी CPU शेड्यूलर्स CPU-बाउंड नेटिव फ़ंक्शंस को निष्पादित करते हैं, जैसे NIF, लिंक्ड-इन ड्राइवर कोड, और BIF जो कि सामान्य एमुलेटर शेड्यूलर द्वारा साफ़-सुथरे ढंग से प्रबंधित नहीं किए जा सकते हैं।

गंदे सीपीयू अनुसूचक धागे की संख्या एमुलेटर बूट समय पर निर्धारित की जाती है और उसके बाद नहीं बदला जा सकता है। हालाँकि, गंदे CPU शेड्यूलर थ्रेड्स की संख्या ऑनलाइन कभी भी बदली जा सकती है। गंदे सीपीयू शेड्यूलर्स की संख्या स्टार्टअप पर कमांड-लाइन फ्लैग +SDcpu या +SDPcpu इन पास करके सेट की जा सकती है erl(1)

यह भी देखें erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline) , erlang:system_info(dirty_cpu_schedulers_online) , erlang:system_info(dirty_io_schedulers) , erlang:system_info(schedulers) , erlang:system_info(schedulers_online) , और erlang:system_flag(schedulers_online, SchedulersOnline)

dirty_cpu_schedulers_online

ऑनलाइन गंदे CPU शेड्यूलर्स की संख्या लौटाता है। वापसी मान को संतुष्ट करता है 1 <= DirtyCPUSchedulersOnline <= N , जहां N की वापसी मान में सबसे छोटी है erlang:system_info(dirty_cpu_schedulers) और erlang:system_info(schedulers_online)

ऑनलाइन गंदे सीपीयू शेड्यूलर्स की संख्या को कमांड-लाइन फ्लैग पास करके स्टार्टअप पर सेट किया जा सकता +SDcpu है erl(1)

अधिक जानकारी के लिए, देखना erlang:system_info(dirty_cpu_schedulers) , erlang:system_info(dirty_io_schedulers) , erlang:system_info(schedulers_online) , और erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline)

dirty_io_schedulers

पूर्णांक के रूप में गंदे I / O शेड्यूलर्स की संख्या लौटाता है। गंदा I / O शेड्यूलर I / O- बाउंड मूल कार्यों को निष्पादित करते हैं, जैसे NIF और लिंक्ड-इन ड्राइवर कोड, जिन्हें सामान्य एमुलेटर शेड्यूलर्स द्वारा साफ-सुथरा प्रबंधित नहीं किया जा सकता है।

इस मान को स्टार्टअप में कमांड-लाइन तर्क पास करके सेट किया जा सकता +SDio है erl(1)

अधिक जानकारी के लिए देखें erlang:system_info(dirty_cpu_schedulers) , erlang:system_info(dirty_cpu_schedulers_online) , और erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline)

multi_scheduling

निम्न में से एक लौटाता है:

disabled

एमुलेटर केवल एक शेड्यूलर थ्रेड के साथ शुरू किया गया है।

blocked

एमुलेटर में एक से अधिक शेड्यूलर थ्रेड होते हैं, लेकिन एक को छोड़कर सभी शेड्यूलर थ्रेड्स अवरुद्ध होते हैं। यही है, केवल एक शेड्यूलर थ्रेड शेड्यूल एर्लैंग प्रोसेस करता है और एर्लैंग कोड निष्पादित करता है।

blocked_normal

एमुलेटर में एक से अधिक शेड्यूलर थ्रेड होते हैं, लेकिन एक को छोड़कर सभी सामान्य शेड्यूलर थ्रेड्स अवरुद्ध होते हैं। ध्यान दें कि गंदे शेड्यूलर अवरुद्ध नहीं हैं, और एर्लांग प्रक्रियाओं को शेड्यूल कर सकते हैं और देशी कोड निष्पादित कर सकते हैं।

enabled

एमुलेटर में एक से अधिक शेड्यूलर थ्रेड होते हैं, और कोई भी शेड्यूलर थ्रेड्स ब्लॉक नहीं होते हैं। यही है, सभी उपलब्ध शेड्यूलर थ्रेड Erlang प्रक्रियाओं को शेड्यूल करते हैं और Erlang कोड निष्पादित करते हैं।

यह भी देखें erlang:system_flag(multi_scheduling, BlockState) , erlang:system_info(multi_scheduling_blockers) , erlang:system_info(normal_multi_scheduling_blockers) , और erlang:system_info(schedulers)

multi_scheduling_blockers

Pid बहु-समय-निर्धारण अवरुद्ध होने पर, s की सूची लौटाता है , अन्यथा खाली सूची वापस आ जाती है। Pid सूची में वर्तमान में अवरुद्ध बहु शेड्यूलिंग सभी प्रक्रियाओं का प्रतिनिधित्व करते हैं। ए Pid सूची में केवल एक बार होता है, भले ही संबंधित प्रक्रिया कई बार अवरुद्ध हो गई हो।

यह भी देखें erlang:system_flag(multi_scheduling, BlockState) , erlang:system_info(multi_scheduling) , erlang:system_info(normal_multi_scheduling_blockers) , और erlang:system_info(schedulers)

normal_multi_scheduling_blockers

Pid सामान्य मल्टी-शेड्यूलिंग को अवरोधित करने पर s की सूची लौटाता है (अर्थात, सभी सामान्य शेड्यूलर लेकिन एक अवरुद्ध है), अन्यथा खाली सूची वापस आ जाती है। Pid सूची में सभी प्रक्रियाओं का प्रतिनिधित्व वर्तमान में साधारण बहु-शेड्यूलिंग अवरुद्ध। ए Pid सूची में केवल एक बार होता है, भले ही संबंधित प्रक्रिया कई बार अवरुद्ध हो गई हो।

यह भी देखें erlang:system_flag(multi_scheduling, BlockState) , erlang:system_info(multi_scheduling) , erlang:system_info(multi_scheduling_blockers) , और erlang:system_info(schedulers)

scheduler_bind_type

उपयोगकर्ता ने शेड्यूलर्स को बाध्य या बाध्य नहीं किया है, इस बारे में जानकारी लौटा दी है।

ध्यान दें कि हालांकि एक उपयोगकर्ता ने अनुसूचियों को बाध्य होने का अनुरोध किया है, वे चुपचाप बांधने में विफल हो सकते हैं। शेड्यूलर बाइंडिंग का निरीक्षण करने के लिए, कॉल करें erlang:system_info(scheduler_bindings)

अधिक जानकारी के लिए कमांड लाइन तर्क को देखने +sbt में erl(1) और erlang:system_info(scheduler_bindings)

scheduler_bindings

वर्तमान में प्रयुक्त शेड्यूलर बाइंडिंग के बारे में जानकारी देता है।

के बराबर आकार का एक टपल erlang:system_info(schedulers) लौटाया जाता है। टपल तत्व पूर्णांक या परमाणु हैं unbound । तार्किक प्रोसेसर पहचानकर्ताओं को पूर्णांक के रूप में दर्शाया गया है। N टपल का वें तत्व शेड्यूलर पहचानकर्ता के साथ अनुसूचक के लिए वर्तमान बंधन के बराबर होता है N । उदाहरण के लिए, यदि शेड्यूलर बाध्य हैं, तो उस element(erlang:system_info(scheduler_id), erlang:system_info(scheduler_bindings)) तार्किक प्रोसेसर के पहचानकर्ता को लौटा देता है जिस पर कॉलिंग प्रक्रिया निष्पादित हो रही है।

ध्यान दें कि केवल ऑनलाइन अनुसूचक तार्किक प्रोसेसर के लिए बाध्य हो सकते हैं।

अधिक जानकारी के लिए कमांड लाइन तर्क को देखने +sbt में erl(1) और erlang:system_info(schedulers_online)

scheduler_id

SchedulerId शेड्यूलर थ्रेड के शेड्यूलर ID ( ) को लौटाता है जिस पर कॉलिंग प्रक्रिया निष्पादित हो रही है। SchedulerId एक सकारात्मक पूर्णांक है, जहां 1 <= SchedulerId <= erlang:system_info(schedulers)

यह भी देखें erlang:system_info(schedulers)

schedulers

एमुलेटर द्वारा उपयोग किए जाने वाले शेड्यूलर थ्रेड्स की संख्या लौटाता है। शेड्यूलर थ्रेड ऑनलाइन शेड्यूल एरलांग प्रोसेस और एरलैंग पोर्ट, और एर्लांग कोड और एर्लैंग लिंक्ड-इन ड्राइवर कोड निष्पादित करते हैं।

शेड्यूलर थ्रेड्स की संख्या एमुलेटर बूट समय पर निर्धारित की जाती है और बाद में इसे बदला नहीं जा सकता है। हालाँकि, ऑनलाइन शेड्यूल करने वालों की संख्या कभी भी बदली जा सकती है।

यह भी देखें erlang:system_flag(schedulers_online, SchedulersOnline) , erlang:system_info(schedulers_online) , scheduler_id , erlang:system_flag(multi_scheduling, BlockState) , erlang:system_info(multi_scheduling) , erlang:system_info(normal_multi_scheduling_blockers) और erlang:system_info(multi_scheduling_blockers)

schedulers_online

ऑनलाइन अनुसूचियों की संख्या लौटाता है। अनुसूचक ऑनलाइन के अनुसूचक पहचानकर्ता रिश्ते को संतुष्ट करते हैं 1 <= SchedulerId <= erlang:system_info(schedulers_online)

अधिक जानकारी के लिए, देखें erlang:system_info(schedulers) और erlang:system_flag(schedulers_online, SchedulersOnline)

smp_support

लौटता है true

threads

लौटता है true

thread_pool_size

एसिंक्रोनस ड्रायवर कॉल ( erl_driver:driver_async() ) के लिए उपयोग किए गए async थ्रेड पूल में async थ्रेड्स की संख्या लौटाता है । मान एक पूर्णांक के रूप में दिया जाता है।

erlang: system_info (आइटम :: निर्माण) -> पूर्णांक ()
erlang: system_info (मद :: विलंबित_नोड_रूप_जीसी) ->
अनंत | पूर्णांक ()> = 0
erlang: system_info (आइटम :: dist) -> बाइनरी ()
erlang: system_info (आइटम :: dist_buf_busy_limit) ->
पूर्णांक ()> = 0
erlang: system_info (आइटम :: dist_ctrl) ->
{नोड :: नोड (),
नियंत्रित करें :: पोर्ट () | पीआईडी ()}

वर्तमान प्रणाली में Erlang वितरण के बारे में जानकारी निम्नानुसार देता है Item :

creation

पूर्णांक के रूप में स्थानीय नोड का निर्माण लौटाता है। नोड के पुनरारंभ होने पर निर्माण बदल दिया जाता है। नोड का निर्माण प्रक्रिया पहचानकर्ताओं, पोर्ट पहचानकर्ताओं और संदर्भों में संग्रहीत होता है। यह एक नोड के विभिन्न अवतारों से पहचानकर्ताओं के बीच अंतर करना संभव बनाता है। मान्य कृतियाँ 1..3 की श्रेणी में पूर्णांक हैं, लेकिन यह संभवतः भविष्य के रिलीज़ में बदल जाएगा। यदि नोड जीवित नहीं है, 0 तो वापस आ गया है।

delayed_node_table_gc

एक नोड तालिका में प्रविष्टि के सेकंड कचरा संग्रह में समय की मात्रा में देरी होती है। यह सीमा स्टार्टअप पर कमांड-लाइन फ्लैग +zdntgc को पास करके सेट की जा सकती है erl(1) । अधिक जानकारी के लिए, कमांड-लाइन ध्वज का दस्तावेज़ीकरण देखें।

dist

Erlang क्रैश डंप के रूप में स्वरूपित की गई वितरण जानकारी की एक स्ट्रिंग युक्त एक बाइनरी लौटाता है। अधिक जानकारी के लिए, How to interpret the Erlang crash dumps उपयोगकर्ता मार्गदर्शिका में अनुभाग देखें ।

dist_buf_busy_limit

बाइट में वितरण बफ़र व्यस्त सीमा का मान लौटाता है। यह सीमा स्टार्टअप पर कमांड-लाइन फ्लैग +zdbbl को पास करके सेट की जा सकती है erl(1)

dist_ctrl

ट्यूपल्स की सूची लौटाता है {Node, ControllingEntity} , प्रत्येक जुड़े रिमोट नोड के लिए एक प्रविष्टि। Node नोड नाम है और ControllingEntity उस नोड के संचार के लिए जिम्मेदार पोर्ट या प्रक्रिया पहचानकर्ता है। अधिक विशेष रूप से, ControllingEntity टीसीपी / आईपी (सामान्य स्थिति) के माध्यम से जुड़े नोड्स के लिए विशिष्ट नोड के साथ संचार में उपयोग किए जाने वाला सॉकेट है।

erlang: system_info (आइटम :: build_type) ->
ऑप्ट |
डिबग |
शुद्ध करना |
परिमाण |
प्योरकोव |
gcov |
valgrind |
gprof |
lcnt |
frmptr
erlang: system_info (आइटम :: c_compiler_used) -> {परमाणु (), शब्द ()}
erlang: system_info (आइटम :: check_io) -> [अवधि ()]
erlang: system_info (आइटम :: compat_rel) -> पूर्णांक ()
erlang: system_info (आइटम :: debug_compiled) -> बूलियन ()
erlang: system_info (आइटम :: ड्राइवर_version) -> स्ट्रिंग ()
erlang: system_info (मद :: डायनेमिक_ट्रेस) ->
कोई नहीं | dtrace | systemtap
erlang: system_info (आइटम :: डायनेमिक_ट्रेस_प्रोब्स) -> बूलियन ()
erlang: system_info (आइटम :: जानकारी) -> बाइनरी ()
erlang: system_info (आइटम :: कर्नेल_पॉल) -> बूलियन ()
erlang: system_info (आइटम :: लोड) -> बाइनरी ()
erlang: system_info (आइटम :: मशीन) -> स्ट्रिंग ()
erlang: system_info (आइटम :: संशोधित_timing_level) ->
पूर्णांक () | अपरिभाषित
erlang: system_info (आइटम :: nif_version) -> स्ट्रिंग ()
erlang: system_info (आइटम :: otp_release) -> स्ट्रिंग ()
erlang: system_info (आइटम :: port_parallelism) -> बूलियन ()
erlang: system_info (आइटम :: system_version) -> स्ट्रिंग ()
erlang: system_info (आइटम :: system_altecture) -> स्ट्रिंग ()
erlang: system_info (मद :: ट्रेस_कंट्रोल_शब्द) ->
पूर्णांक ()> = 0
erlang: system_info (आइटम :: संस्करण) -> स्ट्रिंग ()
erlang: system_info (आइटम ::
शब्दों का | |
{शब्दों का, आंतरिक} | |
{शब्दों का, बाहरी}) ->
4 | 8

वर्तमान प्रणाली (एमुलेटर) के बारे में विभिन्न जानकारी लौटाता है Item :

build_type

रनटाइम सिस्टम के बिल्ड प्रकार का वर्णन करने वाला एक परमाणु लौटाता है। यह सामान्य रूप से opt अनुकूलित के लिए परमाणु है। अन्य संभावित वापसी मान हैं debug , purify , quantify , purecov , gcov , valgrind , gprof , और lcnt । पूर्व सूचना के बिना किसी भी समय संभावित रिटर्न वैल्यूज को जोड़ा या हटाया जा सकता है।

c_compiler_used

रनटाइम सिस्टम को संकलित करते समय उपयोग किए जाने वाले सी कंपाइलर का वर्णन करते हुए एक टू-टपल देता है। पहला तत्व एक परमाणु है जो संकलक के नाम का वर्णन करता है, या undefined यदि अज्ञात है। दूसरा तत्व एक शब्द है जो संकलक के संस्करण का वर्णन करता है, या undefined यदि अज्ञात है।

check_io

एक सूची देता है जिसमें एमुलेटर आंतरिक I / O जाँच के बारे में विविध जानकारी होती है। ध्यान दें कि लौटी हुई सूची की सामग्री प्लेटफार्मों और समय के बीच भिन्न हो सकती है। यह केवल गारंटी है कि एक सूची वापस आ गई है।

compat_rel

पूर्णांक के रूप में स्थानीय नोड की संगतता मोड लौटाता है। पूर्णांक लौटा Erlang / OTP रिलीज का प्रतिनिधित्व करता है कि वर्तमान एमुलेटर के साथ पीछे की ओर संगत किया गया है। संगतता मोड को कमांड-लाइन फ्लैग +R इन का उपयोग करके स्टार्टअप पर कॉन्फ़िगर किया जा सकता है erl(1)

debug_compiled

true यदि एमुलेटर को डीबग-संकलित किया गया है, तो वापस लौटाता है , अन्यथा false

driver_version

रनटाइम सिस्टम द्वारा उपयोग किए जाने वाले एरलैंग ड्राइवर संस्करण युक्त स्ट्रिंग लौटाता है। इसका रूप है "<major ver>.<minor ver>"

dynamic_trace

वर्चुअल मशीन में संकलित डायनामिक ट्रेस फ्रेमवर्क का वर्णन करने वाला एक परमाणु लौटाता है। यह हो सकता है dtrace , systemtap या none । एक वाणिज्यिक या मानक निर्माण के लिए, यह हमेशा होता है none । अन्य रिटर्न मान एक कस्टम कॉन्फ़िगरेशन (उदाहरण के लिए ./configure --with-dynamic-trace=dtrace ) का संकेत देते हैं । डायनेमिक ट्रेसिंग के बारे में अधिक जानकारी के लिए, Erlang सोर्स कोड टॉप डायरेक्टरी में dyntrace(3) मैनुअल पेज और README.dtrace / README.systemtap फाइल्स देखें।

dynamic_trace_probes

boolean() डायनामिक ट्रेस जांच ( dtrace या systemtap ) एमुलेटर में निर्मित होने पर एक संकेत देता है । यह केवल तभी हो सकता है true जब वर्चुअल मशीन को डायनेमिक ट्रेसिंग के लिए बनाया गया हो (यानी, system_info(dynamic_trace) रिटर्न dtrace या systemtap )।

info

Erlang क्रैश डंप के रूप में स्वरूपित एक बाइनरी रिटर्न देता है जिसमें विविध सिस्टम जानकारी होती है। अधिक जानकारी के लिए, How to interpret the Erlang crash dumps उपयोगकर्ता मार्गदर्शिका में अनुभाग देखें ।

kernel_poll

true यदि एमुलेटर किसी प्रकार के कर्नेल-पोल कार्यान्वयन का उपयोग करता है, तो वापस लौटाता है false

loaded

एक बाइनरी लौटाता है जिसमें लोड किए गए मॉड्यूल की एक स्ट्रिंग होती है जिसे एरलैंग क्रैश डंप के रूप में स्वरूपित किया जाता है। अधिक जानकारी के लिए, How to interpret the Erlang crash dumps उपयोगकर्ता मार्गदर्शिका में अनुभाग देखें ।

machine

Erlang मशीन नाम युक्त स्ट्रिंग लौटाता है।

modified_timing_level

संशोधित समय-स्तर (एक पूर्णांक) लौटाता है यदि संशोधित समय सक्षम किया जाता है, अन्यथा undefined । संशोधित समय के बारे में अधिक जानकारी के लिए, कमांड-लाइन ध्वज +T को देखें erl(1)

nif_version

एक स्ट्रिंग लौटाता है जिसमें रनटाइम सिस्टम द्वारा उपयोग किए गए Erlang NIF इंटरफ़ेस का संस्करण होता है। यह "<प्रमुख क्रिया> <<मामूली क्रिया>" फ़ॉर्म पर है।

otp_release

OTP रिलीज़ की OTP रिलीज़ संख्या के साथ एक स्ट्रिंग देता है जो वर्तमान में ERTS एप्लिकेशन को निष्पादित कर रहा है।

Erlang / OTP 17 से, OTP रिलीज़ संख्या प्रमुख OTP संस्करण संख्या से मेल खाती है। कोई भी erlang:system_info() तर्क सटीक OTP संस्करण नहीं देता है। ऐसा इसलिए है क्योंकि सामान्य स्थिति में सटीक OTP संस्करण निर्धारित करना मुश्किल है। अधिक जानकारी के लिए, System principles सिस्टम प्रलेखन में संस्करणों का विवरण देखें ।

port_parallelism

डिफ़ॉल्ट पोर्ट समानांतरवाद शेड्यूलिंग संकेत का उपयोग करता है। अधिक जानकारी के लिए कमांड लाइन तर्क को देखने +spp में erl(1)

system_version

संस्करण संख्या और कुछ महत्वपूर्ण गुणों से युक्त एक स्ट्रिंग लौटाता है, जैसे कि अनुसूचियों की संख्या।

system_architecture

प्रोसेसर और OS आर्किटेक्चर युक्त एक स्ट्रिंग देता है, जिसके लिए एमुलेटर बनाया गया है।

trace_control_word

नोड ट्रेस नियंत्रण शब्द का मान लौटाता है। अधिक जानकारी के लिए, उपयोगकर्ता के गाइड get_tcw में अनुभाग देखें Match Specifications in Erlang

version

एमुलेटर के संस्करण संख्या से युक्त एक स्ट्रिंग लौटाता है।

wordsize

के रूप में ही {wordsize, internal}

{wordsize, internal}

बाइट्स में एर्लैंग शब्द के आकार को पूर्णांक के रूप में लौटाता है, अर्थात 4 को 32-बिट आर्किटेक्चर पर लौटाया जाता है, और 8 को शुद्ध 64-बिट आर्किटेक्चर पर लौटाया जाता है। हाफवर्ड 64-बिट एमुलेटर पर, 4 को लौटाया जाता है, क्योंकि अर्लंग शब्द आधे सिस्टम शब्द आकार के एक आभासी शब्द आकार का उपयोग करके संग्रहीत किया जाता है।

{wordsize, external}

एमुलेटर का सही शब्द आकार, यानी पॉइंटर का आकार लौटाता है। मान बाइट्स में पूर्णांक के रूप में दिया जाता है। शुद्ध 32-बिट आर्किटेक्चर पर, 4 को लौटाया जाता है। आधे शब्द पर और शुद्ध 64-बिट वास्तुकला पर, 8 वापस आ गया है।

erlang: system_monitor () -> MonSettings

प्रकार

वर्तमान सिस्टम मॉनिटरिंग सेटिंग्स को इस प्रकार सेट erlang:system_monitor/2 करता है {MonitorPid, Options} , या undefined यदि कोई सेटिंग मौजूद नहीं है। विकल्पों का क्रम उस सेट से भिन्न हो सकता है जिसे सेट किया गया था।

erlang: system_monitor (Arg) -> मोनसेटिंग

प्रकार

जब तर्क के साथ कहा जाता है undefined , तो सभी सिस्टम प्रदर्शन निगरानी सेटिंग्स साफ़ हो जाती हैं।

फ़ंक्शन {MonitorPid, Options} को तर्क के रूप में कॉल करना कॉलिंग के समान है erlang:system_monitor/2

पिछले सिस्टम मॉनिटर सेटिंग्स को वैसे ही लौटाता है erlang:system_monitor/0

erlang: system_monitor (MonitorPid, Options) -> MonSettings

प्रकार

सिस्टम प्रदर्शन निगरानी विकल्प सेट करता है। MonitorPid एक स्थानीय प्रक्रिया पहचानकर्ता (pid) है जो सिस्टम मॉनिटर संदेश प्राप्त करता है। दूसरा तर्क निगरानी विकल्पों की सूची है:

{long_gc, Time}

प्रणाली में एक कचरा संग्रहण कम से कम लेता है Time दीवार घड़ी मिलीसेकेंड, संदेश {monitor, GcPid, long_gc, Info} को भेजा जाता है MonitorPid GcPid वह कूड़ा है जिसे कचरा एकत्र किया गया था। Info कचरे के संग्रह के परिणाम का वर्णन करने वाले दो-तत्व ट्यूपल्स की एक सूची है।

टुपल्स में से एक है {timeout, GcTime} , जहां GcTime मिलीसेकंड में कचरा संग्रहण का समय होता है। अन्य tuples के साथ टैग कर रहे हैं heap_size , heap_block_size , stack_size , mbuf_size , old_heap_size , और old_heap_block_size । इन टुपल्स को ट्रेस संदेश gc_minor_start (देखें erlang:trace/3 ) के विवरण में समझाया गया है । नई ट्यूपल्स को जोड़ा जा सकता है, और Info सूची में ट्यूपल्स के क्रम को बिना किसी पूर्व सूचना के कभी भी बदला जा सकता है।

{long_schedule, Time}

यदि सिस्टम में कोई प्रक्रिया या पोर्ट कम से कम Time दीवार घड़ी मिलीसेकंड के लिए निर्बाध चलता है , तो एक संदेश {monitor, PidOrPort, long_schedule, Info} भेजा जाता है MonitorPid PidOrPort प्रक्रिया या पोर्ट है जो चल रहा था। Info घटना का वर्णन करने वाले दो-तत्व ट्यूपल्स की एक सूची है।

यदि a pid() , ट्यूपल्स {timeout, Millis} , {in, Location} और {out, Location} मौजूद हैं, जहां Location या तो एक MFA ( {Module, Function, Arity} ) फ़ंक्शन का वर्णन करता है जहां प्रक्रिया / बाहर या परमाणु में निर्धारित की गई थी undefined

यदि ए port() , टुपल्स {timeout, Millis} और {port_op,Op} मौजूद हैं। Op में से एक है proc_sig , timeout , input , output , event , या dist_cmd पर जो ड्राइवर कॉलबैक को क्रियान्वित किया गया था निर्भर करता है,।

proc_sig जबकि दूसरों को इसी चालक कॉलबैक प्रतिनिधित्व करते हैं, एक आंतरिक ऑपरेशन है और प्रकट करने के लिए कभी नहीं है timeout , ready_input , ready_output , event , और outputv (बंदरगाह वितरण द्वारा प्रयोग किया जाता है जब)। Millis टपल में मूल्य timeout प्रक्रिया या पोर्ट के निर्बाध निष्पादन समय के बारे में सूचित करता है, जो Time ट्रेस शुरू करते समय हमेशा आपूर्ति के मूल्य के बराबर या अधिक होता है । Info भविष्य में रिलीज़ में नई ट्यूपल्स को सूची में जोड़ा जा सकता है । सूची में टुपल्स के क्रम को बिना किसी पूर्व सूचना के कभी भी बदला जा सकता है।

इसका उपयोग NIF या ड्राइवरों के साथ समस्याओं का पता लगाने के लिए किया जा सकता है, जिन्हें निष्पादित करने में बहुत लंबा समय लगता है। 1 एमएस को ड्राइवर कॉलबैक या एनआईएफ के लिए एक अच्छा अधिकतम समय माना जाता है। हालांकि, एक समय-साझाकरण प्रणाली आमतौर पर हर चीज पर विचार करना चाहती है <100 ms "संभव" और काफी "सामान्य"। हालाँकि, अधिक समय शेड्यूलिंग स्वैपिंग या दुर्व्यवहार NIF / ड्राइवर का संकेत दे सकता है। NIF और ड्राइवरों को दुर्व्यवहार करने से खराब संसाधन उपयोग और खराब समग्र प्रणाली प्रदर्शन हो सकता है।

{large_heap, Size}

यदि सिस्टम में एक कचरा संग्रह एक ढेर के आवंटित आकार में परिणामित होता है, तो कम से कम Size एक संदेश {monitor, GcPid, large_heap, Info} भेजा जाता है MonitorPid GcPid और पहले Info की तरह ही हैं long_gc , सिवाय इसके कि टपल टैग के साथ timeout मौजूद नहीं है।

मॉनिटर संदेश तब भेजा जाता है जब कचरा संग्रहण के बाद या उससे अधिक के बराबर सभी ढेर पीढ़ियों के लिए आवंटित सभी मेमोरी ब्लॉकों के आकार का योग Size

जब किसी प्रक्रिया को मार दिया जाता है process_flag(max_heap_size,Size) , तो कचरा संग्रह पूरा होने से पहले इसे मार दिया जाता है और इस प्रकार कोई बड़ा ढेर संदेश नहीं भेजा जाता है।

busy_port

यदि सिस्टम में एक प्रक्रिया निलंबित हो जाती है क्योंकि यह एक व्यस्त पोर्ट को भेजता है, तो एक संदेश {monitor, SusPid, busy_port, Port} भेजा जाता है MonitorPid SusPid वह पीड है जिसे भेजने पर निलंबित कर दिया गया Port

busy_dist_port

यदि सिस्टम में एक प्रक्रिया निलंबित हो जाती है क्योंकि यह एक दूरस्थ नोड पर एक प्रक्रिया को भेजता है जिसका अंतर नोड संचार एक व्यस्त बंदरगाह द्वारा नियंत्रित किया गया था, तो एक संदेश {monitor, SusPid, busy_dist_port, Port} भेजा जाता है MonitorPid SusPid इंटर-नोड संचार पोर्ट के माध्यम से भेजने पर निलंबित कर दिया गया है कि पीआईडी ​​है Port

पिछले सिस्टम मॉनिटर सेटिंग्स को वैसे ही लौटाता है erlang:system_monitor/0

ध्यान दें

यदि एक निगरानी प्रक्रिया इतनी बड़ी हो जाती है कि यह कचरा एकत्रित करते समय सिस्टम मॉनिटर संदेशों का कारण बनती है, तो संदेश प्रक्रिया संदेश कतार को बड़ा करते हैं और संभवतः समस्या को और अधिक बदतर बना देते हैं।

मॉनिटरिंग प्रक्रिया को साफ-सुथरा रखें और सिस्टम मॉनिटर की सीमा को बहुत अधिक तंग न करें।

विफलताएं:

badarg
अगर MonitorPid मौजूद नहीं है।
badarg
यदि MonitorPid एक स्थानीय प्रक्रिया नहीं है।
erlang: system_profile () -> ProfilerSettings

प्रकार

वर्तमान सिस्टम प्रोफाइलिंग सेटिंग को उस erlang:system_profile/2 रूप {ProfilerPid, Options} में या undefined यदि कोई सेटिंग नहीं है , तो लौटाता है । विकल्पों का क्रम उस सेट से भिन्न हो सकता है जिसे सेट किया गया था।

erlang: system_profile (ProfilerPid, Options) -> ProfilerSettings

प्रकार

सिस्टम प्रोफाइलर विकल्प सेट करता है। ProfilerPid एक स्थानीय प्रक्रिया पहचानकर्ता (pid) या प्रोफाइलिंग संदेश प्राप्त करने वाला पोर्ट है। रिसीवर को सभी प्रोफाइलिंग से बाहर रखा गया है। दूसरा तर्क प्रोफाइलिंग विकल्पों की एक सूची है:

exclusive

यदि किसी प्रक्रिया से पोर्ट के लिए एक सिंक्रोनस कॉल किया जाता है, तो कॉल रनटाइम को पोर्ट के दौरान कॉल रन करने योग्य नहीं माना जाता है। कॉलिंग प्रक्रिया को अधिसूचित किया जाता है inactive , और बाद में active जब पोर्ट कॉलबैक वापस आता है।

monotonic_timestamp

प्रोफ़ाइल संदेशों में समय टिकटों का उपयोग करें Erlang monotonic time । टाइम स्टैम्प (टीएस) का एक ही प्रारूप और मूल्य है जैसा कि उत्पादन किया गया है erlang:monotonic_time(nanosecond)

runnable_procs

यदि एक प्रक्रिया रन क्यू से डाली या हटा दी जाती है, तो एक संदेश {profile, Pid, State, Mfa, Ts} , को भेजा जाता है ProfilerPid । पूर्व-खाली होने के बाद रनिंग कतार में फिर से चलने वाली प्रक्रियाएँ इस संदेश को ट्रिगर नहीं करती हैं।

runnable_ports

यदि किसी पोर्ट को रन कतार से डाला या हटाया जाता है, तो एक संदेश {profile, Port, State, 0, Ts} , को भेजा जाता है ProfilerPid

scheduler

यदि किसी शेड्यूलर को सोने या जागने के लिए रखा जाता है, तो उसे एक संदेश {profile, scheduler, Id, State, NoScheds, Ts} भेजा जाता है ProfilerPid

strict_monotonic_timestamp

प्रोफ़ाइल संदेशों में टाइम स्टैम्प Erlang monotonic time और एक नीरस रूप से बढ़ते पूर्णांक से मिलकर बनता है । टाइम स्टैम्प (टीएस) का एक ही प्रारूप और मूल्य है जैसा कि उत्पादन किया गया है {erlang:monotonic_time(nanosecond), erlang:unique_integer([monotonic])}

timestamp

प्रोफ़ाइल संदेशों में टाइम स्टैम्प में एक टाइम स्टैम्प (Ts) शामिल होता है जो उसी रूप में होता है जो उसके द्वारा लौटाया जाता है erlang:now() । यह भी डिफ़ॉल्ट है यदि कोई समय टिकट ध्वज निर्दिष्ट नहीं है। यदि cpu_timestamp इसके माध्यम से सक्षम किया गया है erlang:trace/3 , तो यह ध्वज timestamp सक्षम होने पर प्रोफाइलिंग संदेशों में उत्पादित समय स्टाम्प को भी प्रभावित करता है।

ध्यान दें

erlang:system_profile व्यवहार भविष्य में रिलीज़ में बदल सकता है।

erlang: system_time () -> पूर्णांक ()

में करंट लौटता Erlang system time है native time_unit()

कॉलिंग erlang:system_time() के बराबर है erlang:monotonic_time() + erlang:time_offset()

ध्यान दें

यह समय सामान्य मामले में एक नीरस रूप से बढ़ता समय नहीं है। अधिक जानकारी के लिए, time warp modes उपयोगकर्ता गाइड में प्रलेखन देखें ।

erlang: system_time (यूनिट) -> पूर्णांक ()

प्रकार

लौटे वर्तमान को तर्क के रूप Erlang system time में परिवर्तित कर Unit दिया जाता है।

कॉलिंग erlang:system_time(Unit) के बराबर है erlang:convert_time_unit/3 ( erlang:system_time() , native, Unit)

ध्यान दें

यह समय सामान्य मामले में एक नीरस रूप से बढ़ता समय नहीं है। अधिक जानकारी के लिए, time warp modes उपयोगकर्ता गाइड में प्रलेखन देखें ।

term_to_binary (शब्द) -> ext_binary()

प्रकार

एक बाइनरी डेटा ऑब्जेक्ट लौटाता है जो कि एन्कोडिंग के Term अनुसार परिणाम है Erlang external term format.

इसका उपयोग विभिन्न उद्देश्यों के लिए किया जा सकता है, उदाहरण के लिए, एक फाइल को एक कुशल तरीके से लिखना, या किसी प्रकार के संचार चैनल को एर्लैंग शब्द भेजना जो वितरित एर्लांग द्वारा समर्थित नहीं है।

> Bin = term_to_binary(hello).
<<131,100,0,5,104,101,108,108,111>>
> hello = binary_to_term(Bin).
hello

यह भी देखें binary_to_term/1

ध्यान दें

इस बात की कोई गारंटी नहीं है कि यह फ़ंक्शन समान शब्द के लिए समान एन्कोडेड प्रतिनिधित्व लौटाएगा।

term_to_binary (शब्द, विकल्प) -> ext_binary()

प्रकार

एक बाइनरी डेटा ऑब्जेक्ट लौटाता है Term जो एर्लांग बाहरी शब्द प्रारूप के अनुसार एन्कोडिंग का परिणाम है ।

यदि विकल्प compressed प्रदान किया गया है, तो बाहरी शब्द प्रारूप संकुचित है। संपीड़ित प्रारूप स्वचालित binary_to_term/1 रूप से Erlang / OTP R7B से मान्यता प्राप्त है ।

एक संपीड़न स्तर विकल्प देकर निर्दिष्ट किया जा सकता है {compressed, Level} Level 0..9 की सीमा वाला पूर्णांक है, जहां:

  • 0 - कोई संपीड़न नहीं किया जाता है (यह बिना compressed विकल्प देने के समान है)।

  • 1 - कम से कम समय लेता है लेकिन उच्च स्तर के साथ-साथ संपीड़ित नहीं कर सकता है।

  • 6 - डिफ़ॉल्ट स्तर जब विकल्प compressed प्रदान किया जाता है।

  • 9 - अधिकांश समय लेता है और एक छोटे परिणाम का उत्पादन करने की कोशिश करता है। पूर्ववर्ती वाक्य में "कोशिश" नोटिस; इनपुट अवधि के आधार पर, स्तर 9 संपीड़न या तो स्तर 1 संपीड़न की तुलना में एक छोटे परिणाम का उत्पादन करता है या नहीं करता है।

{minor_version, Version} कुछ एन्कोडिंग विवरण को नियंत्रित करने के लिए विकल्प का उपयोग किया जा सकता है। यह विकल्प Erlang / OTP R11B-4 में पेश किया गया था। इसके लिए मान्य मान Version हैं:

0

एक पाठीय प्रतिनिधित्व का उपयोग करके फ़्लोट्स एन्कोड किए गए हैं। यह विकल्प यह सुनिश्चित करने के लिए उपयोगी है कि Erlang / OTP R11B-4 से पहले रिलीज होने से परिणामी बाइनरी को डिकोड किया जा सकता है।

यह संस्करण उन परमाणुओं को एनकोड करता है जिन्हें एक लेट 1 स्ट्रिंग का प्रतिनिधित्व किया जा सकता है।

1

यह Erlang / OTP 17.0 के रूप में डिफ़ॉल्ट है। यह किसी भी स्थान को एक अधिक स्थान-कुशल और सटीक तरीके से कूटबद्ध करने के लिए मजबूर करता है (अर्थात् 64-बिट IEEE प्रारूप में, एक पाठीय प्रतिनिधित्व में परिवर्तित होने के बजाय)। Erlang / OTP R11B-4 से, binary_to_term/1 इस प्रतिनिधित्व को डिकोड कर सकता है।

यह संस्करण उन परमाणुओं को एनकोड करता है जिन्हें एक लेट 1 स्ट्रिंग का प्रतिनिधित्व किया जा सकता है।

2

लैटिन 1 परमाणु एन्कोडिंग का उपयोग छोड़ देता है और सभी परमाणुओं के लिए बिना उपयोग के utf8 एन्कोडिंग का उपयोग करता है। इसे भविष्य में Erlang / OTP की प्रमुख रिलीज़ में डिफ़ॉल्ट में बदल दिया जाएगा। R16B के रूप में एरलैंग / ओटीपी सिस्टम इस प्रतिनिधित्व को डिकोड कर सकते हैं।

यह भी देखें binary_to_term/1

फेंक (किसी भी) -> no_return ()

प्रकार

एक समारोह से एक गैर-स्थानीय वापसी। यदि एक के भीतर मूल्यांकन किया जाता है catch , तो catch मान लौटाता है Any । उदाहरण:

> catch throw({hello, there}).
{hello,there}

विफलता: nocatch यदि किसी कैच के भीतर मूल्यांकन नहीं किया गया है।

समय () -> समय

प्रकार

के रूप में वर्तमान समय देता है {Hour, Minute, Second}

समय क्षेत्र और डेलाइट सेविंग टाइम सुधार अंतर्निहित OS पर निर्भर करता है। उदाहरण:

> time().
{9,42,44}
erlang: time_offset () -> पूर्णांक ()

के बीच Erlang monotonic time और Erlang system time में ऑफसेट वर्तमान समय देता है native time_unit() । एर्लांग मोनोटोनिक समय में जोड़े गए वर्तमान समय की ऑफसेट एर्लंग प्रणाली का समय देता है।

समय ऑफसेट time warp mode उपयोग के आधार पर ऑपरेशन के दौरान बदल सकता है या नहीं भी हो सकता है।

ध्यान दें

समय में बदलाव को विभिन्न प्रक्रियाओं द्वारा समय में थोड़ा अलग बिंदुओं पर देखा जा सकता है।

यदि रनटाइम सिस्टम चालू है multi-time warp mode , तो रनटाइम सिस्टम पता लगाता है कि कब OS system time बदल गया है। हालांकि, रनटाइम सिस्टम ऐसा होने पर तुरंत इसका पता नहीं लगाएगा। समय ऑफसेट की जांच करने वाला कार्य एक मिनट में कम से कम एक बार निष्पादित करने के लिए निर्धारित है; इसलिए, सामान्य ऑपरेशन के तहत यह एक मिनट के भीतर पता लगाया जाना है, लेकिन भारी भार के दौरान इसमें अधिक समय लग सकता है।

erlang: time_offset (यूनिट) -> पूर्णांक ()

प्रकार

वर्तमान समय को बीच में ऑफसेट करता है Erlang monotonic time और तर्क के रूप Erlang system time में परिवर्तित Unit हो जाता है।

erlang:convert_time_unit/3 ( erlang:time_offset() , native, Unit) हालांकि आमतौर पर उपयोग किए जाने वाले Unit एस के लिए अनुकूलित कॉलिंग के रूप में भी ।

erlang: टाइमस्टैम्प () -> टाइमस्टैम्प

प्रकार

Erlang system time प्रारूप पर वर्तमान देता है {MegaSecs, Secs, MicroSecs} । इस प्रारूप के समान ही है os:timestamp/0 और बहिष्कृत erlang:now/0 उपयोग। erlang:timestamp() इस समय के स्टैम्प प्रारूप को मानने वाले मौजूदा कोड के उपयोग को सरल बनाने के लिए इसका अस्तित्व का कारण है वर्तमान एरलैंग प्रणाली का समय अपनी पसंद के समय इकाई में अधिक कुशलता से पुनर्प्राप्त किया जा सकता है erlang:system_time/1

erlang:timestamp() BIF के बराबर है:

timestamp() ->
    ErlangSystemTime = erlang:system_time(microsecond),
    MegaSecs = ErlangSystemTime div 1000000000000,
    Secs = ErlangSystemTime div 1000000 - MegaSecs*1000000,
    MicroSecs = ErlangSystemTime rem 1000000,
    {MegaSecs, Secs, MicroSecs}.

हालांकि, यह एक देशी कार्यान्वयन का उपयोग करता है जो ढेर पर कचरा नहीं बनाता है और थोड़ा बेहतर प्रदर्शन के साथ।

ध्यान दें

यह समय सामान्य मामले में एक नीरस रूप से बढ़ता समय नहीं है। अधिक जानकारी के लिए, time warp modes उपयोगकर्ता गाइड में प्रलेखन देखें ।

tl (सूची) -> पद ()

प्रकार

की तालिका लौटाता है, अर्थात् List , सूची में पहला तत्व घटा है, उदाहरण के लिए:

> tl([geesties, guilies, beasties]).
[guilies, beasties]

गार्ड परीक्षण में अनुमति है।

असफलता: badarg अगर List खाली सूची है []

erlang: ट्रेस (PidPortSpec, How, FlagList) -> पूर्णांक ()

प्रकार

ट्रेस (यदि How == true ) या बंद (यदि How == false ) ट्रेस झंडे FlagList प्रक्रिया या प्रक्रियाओं के लिए प्रतिनिधित्व करते हैं PidPortSpec

PidPortSpec स्थानीय प्रक्रिया, पोर्ट पहचानकर्ता या निम्न परमाणुओं में से एक के लिए या तो एक प्रक्रिया पहचानकर्ता (पीआईडी) है:

all
वर्तमान में सभी मौजूदा प्रक्रियाएं और बंदरगाह और भविष्य में बनने वाले सभी।
processes
वर्तमान में सभी मौजूदा प्रक्रियाएं और भविष्य में बनाई जाने वाली सभी प्रक्रियाएं।
ports
वर्तमान में सभी मौजूदा बंदरगाह और भविष्य में बनाए जाएंगे।
existing
वर्तमान में सभी मौजूदा प्रक्रियाएं और पोर्ट।
existing_processes
वर्तमान में सभी मौजूदा प्रक्रियाएँ।
existing_ports
वर्तमान में सभी मौजूदा बंदरगाह।
new
भविष्य में बनने वाली सभी प्रक्रिया और पोर्ट।
new_processes
भविष्य में बनने वाली सभी प्रक्रियाएं।
new_ports
भविष्य में बनने वाले सभी पोर्ट।

FlagList निम्नलिखित झंडे में से किसी भी संख्या में हो सकता है ("संदेश टैग" की सूची को संदर्भित करता है trace messages ):

all

सिवाय सभी ट्रेस झंडे सेट करता है tracer और cpu_timestamp , जो कि उनकी प्रकृति में दूसरों की तुलना में अलग हैं।

send

संदेश भेजना।

संदेश टैग: send और send_to_non_existing_process

'receive'

संदेश प्राप्त करना।

संदेश टैग: 'receive'

call

कुछ फ़ंक्शन कॉल का पता लगाता है। निर्दिष्ट करें कि कौन सा फ़ंक्शन कॉल करके ट्रेस करता है erlang:trace_pattern/3

संदेश टैग: call और return_from

silent

call ट्रेस ध्वज के साथ प्रयोग किया जाता है । call , return_from , और return_to पता लगाने अगर यह ध्वज सेट है संदेशों हिचकते हैं, लेकिन अगर कोई मैच विनिर्देशों हैं वे सामान्य रूप में क्रियान्वित कर रहे हैं।

साइलेंट मोड को निष्पादित erlang:trace(_, false, [silent|_]) या मैच विनिर्देश द्वारा फ़ंक्शन को निष्पादित करने से रोक दिया जाता है {silent, false}

silent ट्रेस ध्वज कई या यहाँ तक कि सिस्टम में सभी प्रक्रियाओं पर एक निशान की स्थापना की सुविधा। इसके बाद ट्रेस को सक्रिय किया जा सकता है और मैच स्पेसिफिकेशन फ़ंक्शन का उपयोग करके निष्क्रिय किया जा सकता है {silent,Bool} , जिससे यह पता चलता है कि कौन से तर्क ट्रेस करने वाले कार्यों का उच्च स्तर देते हैं।

संदेश टैग: call , return_from , और return_to । या बल्कि, की अनुपस्थिति।

return_to

call ट्रेस ध्वज के साथ प्रयोग किया जाता है । एक निशान समारोह से वापस आने के लिए अपने फोन करने वाले का पता लगाता है। केवल विकल्प के साथ ट्रेस किए गए कार्यों के लिए काम करता local है erlang:trace_pattern/3

शब्दार्थ यह है कि कॉल ट्रेस किए गए फ़ंक्शन के वापस आने पर एक ट्रेस संदेश भेजा जाता है, अर्थात, जब पूंछ पुनरावर्ती कॉल की एक श्रृंखला समाप्त होती है। पूंछ पुनरावर्ती कॉल की केवल एक ट्रेस संदेश प्रति श्रृंखला भेजी जाती है, इसलिए फ़ंक्शन कॉल्स के लिए पूंछ पुनरावृत्ति के गुणों को इस ध्वज के साथ ट्रेस करते समय रखा जाता है। एक साथ उपयोग करना call और return_to ट्रेस करना यह ठीक से जानना संभव बनाता है कि किसी भी समय किसी प्रक्रिया को कैसे निष्पादित किया जाता है।

कार्यों से रिटर्न वैल्यू वाले ट्रेस संदेश प्राप्त करने के लिए, {return_trace} इसके बजाय मैच विनिर्देश कार्रवाई का उपयोग करें।

संदेश टैग: return_to

procs

प्रक्रिया से संबंधित घटनाओं का पता लगाता है।

संदेश टैग: spawn , spawned , exit , register , unregister , link , unlink , getting_linked , और getting_unlinked

ports

पोर्ट से संबंधित घटनाओं का पता लगाता है।

संदेश टैग: open , closed , register , unregister , getting_linked , और getting_unlinked

running

प्रक्रियाओं का समय निर्धारण करता है।

संदेश टैग: in और out

exiting

प्रक्रियाओं से बाहर निकलने का समय निर्धारित करता है।

संदेश टैग: in_exiting , out_exiting , और out_exited

running_procs

जैसे प्रक्रियाओं का समय निर्धारण करता है running । हालाँकि, इस विकल्प में शेड्यूल ईवेंट भी शामिल हैं, जब प्रक्रिया पोर्ट के संदर्भ में निष्पादित होती है, बिना शेड्यूल किए।

संदेश टैग: in और out

running_ports

बंदरगाहों के समय निर्धारण का पता लगाता है।

संदेश टैग: in और out

garbage_collection

प्रक्रियाओं के कचरा संग्रह का पता लगाता है।

संदेश टैग: gc_minor_start , gc_max_heap_size , और gc_minor_end

timestamp

सभी ट्रेस संदेशों में एक समय टिकट शामिल है। टाइम स्टैम्प (Ts) के रूप में उसी रूप में होता है जो वापस लौटा दिया जाता है erlang:now()

cpu_timestamp

एर्लैंग नोड के लिए एक वैश्विक ट्रेस ध्वज timestamp जो सीपीयू समय में ध्वज का उपयोग करके सभी ट्रेस टाइम स्टैम्प बनाता है , न कि दीवार घड़ी समय। यानि सक्षम होने या cpu_timestamp न होने पर इसका उपयोग नहीं किया जाता है। के साथ ही अनुमति दी । यदि होस्ट मशीन ओएस उच्च-रिज़ॉल्यूशन सीपीयू समय माप का समर्थन नहीं करता है, तो बाहर निकलता है । ध्यान दें कि अधिकांश OS कोर के पार इस मान को सिंक्रनाइज़ नहीं करते हैं, इसलिए तैयार रहें कि इस विकल्प का उपयोग करते समय पीछे की ओर जाने में समय लग सकता है। monotonic_timestamp strict_monotonic_timestamp PidPortSpec==all trace/3 badarg

monotonic_timestamp

Erlang monotonic time सभी ट्रेस संदेशों में एक समय टिकट शामिल है । टाइम स्टैम्प (टीएस) का एक ही प्रारूप और मूल्य है जैसा कि उत्पादन किया गया है erlang:monotonic_time(nanosecond) । यह झंडा झंडा फहराता है cpu_timestamp

strict_monotonic_timestamp

Erlang monotonic time सभी ट्रेस संदेशों में एक टाइम स्टांप और एक नीरस रूप से बढ़ते पूर्णांक शामिल हैं। टाइम स्टैम्प (टीएस) का एक ही प्रारूप और मूल्य है जैसा कि उत्पादन किया गया है { erlang:monotonic_time(nanosecond) , erlang:unique_integer([monotonic]) } । यह झंडा झंडा फहराता है cpu_timestamp

arity

call ट्रेस ध्वज के साथ प्रयोग किया जाता है । कॉल ट्रेस संदेशों के {M, F, Arity} बजाय निर्दिष्ट किया गया है {M, F, Args}

set_on_spawn

एक ट्रेस प्रक्रिया द्वारा बनाई गई किसी भी प्रक्रिया को ध्वज सहित अपने ट्रेस झंडे विरासत में मिलते हैं set_on_spawn

set_on_first_spawn

एक ट्रेस प्रक्रिया द्वारा बनाई गई पहली प्रक्रिया को झंडे को छोड़कर अपने ट्रेस झंडे विरासत में मिलते हैं set_on_first_spawn

set_on_link

एक ट्रेस प्रक्रिया से जुड़ी किसी भी प्रक्रिया को ध्वज सहित अपने ट्रेस झंडे विरासत में मिलते हैं set_on_link

set_on_first_link

एक ट्रेस प्रक्रिया से जुड़ी पहली प्रक्रिया को ध्वज को छोड़कर अपने ट्रेस झंडे विरासत में मिलते हैं set_on_first_link

{tracer, Tracer}

निर्दिष्ट करता है कि ट्रेस संदेश कहां भेजें। Tracer स्थानीय प्रक्रिया या स्थानीय पोर्ट के पोर्ट पहचानकर्ता की प्रक्रिया पहचानकर्ता होनी चाहिए।

{tracer, TracerModule, TracerState}

निर्दिष्ट करता है कि ट्रेस संदेश भेजने के बजाय एक ट्रैसर मॉड्यूल को बुलाया जाना है। ट्रैसर मॉड्यूल तब ट्रेस संदेश को अनदेखा या बदल सकता है। ट्रैसर मॉड्यूल लिखने के तरीके के बारे में अधिक जानकारी के लिए, देखें erl_tracer(3)

यदि कोई tracer निर्दिष्ट नहीं है, तो कॉलिंग प्रक्रिया सभी ट्रेस संदेश प्राप्त करती है।

set_on_first_link साथ संयोजन का प्रभाव अकेले के set_on_link रूप में होता set_on_first_link है। इसी तरह के लिए set_on_spawn और set_on_first_spawn

ट्रेसिंग प्रक्रिया निम्न सूची में वर्णित ट्रेस संदेशों को प्राप्त करती है । Pid ट्रेस प्रक्रिया की प्रक्रिया पहचानकर्ता है जिसमें ट्रेस की गई घटना हुई है। तीसरा टपल तत्व संदेश टैग है।

यदि ध्वज timestamp , strict_monotonic_timestamp या monotonic_timestamp निर्दिष्ट किया गया है, तो पहला टपल तत्व trace_ts इसके बजाय है, और समय स्टैंप को संदेश टपल में अंतिम तत्व के रूप में जोड़ा जाता है। यदि कई बार स्टैम्प फ्लैग पास किए जाते हैं, तो timestamp पूर्ववर्तीता अधिक होती है strict_monotonic_timestamp , जो बदले में पूर्ववर्तीता होती है monotonic_timestamp । हर समय स्टैम्प फ्लैग को याद किया जाता है, इसलिए यदि दो को पास कर दिया जाए और बाद में सर्वोच्च वरीयता वाला एक विकलांग हो जाए, तो दूसरा सक्रिय हो जाता है।

संदेश ट्रेस करें:

{trace, PidPort, send, Msg, To}

जब प्रक्रिया के लिए PidPort संदेश भेजता Msg है To

{trace, PidPort, send_to_non_existing_process, Msg, To}

जब गैर-मौजूदा प्रक्रिया को PidPort संदेश भेजता Msg है To

{trace, PidPort, 'receive', Msg}

जब PidPort संदेश प्राप्त होता है Msg । यदि Msg टाइम-आउट के लिए सेट किया गया है, तो एक प्राप्त बयान का समय समाप्त हो सकता है, या प्रक्रिया को पेलोड के साथ एक संदेश प्राप्त हुआ timeout

{trace, Pid, call, {M, F, Args}}

जब Pid एक ट्रेस फ़ंक्शन को कॉल करता है। कॉल के रिटर्न मान कभी भी आपूर्ति नहीं किए जाते हैं, केवल कॉल और उसके तर्क।

ट्रेस ध्वज arity का उपयोग इस संदेश की सामग्री को बदलने के लिए किया जा सकता है, इसलिए Arity इसके बजाय निर्दिष्ट किया जाता है Args

{trace, Pid, return_to, {M, F, Arity}}

जब निर्दिष्ट फ़ंक्शन पर Pid लौटता है । यह ट्रेस संदेश भेजा जाता है अगर दोनों झंडे call और return_to सेट हैं, और फ़ंक्शन को स्थानीय फ़ंक्शन कॉल पर पता लगाया जाना है । संदेश केवल तभी पुनरावर्ती फ़ंक्शन कॉल की एक श्रृंखला से लौटते समय भेजा जाता है, जहां कम से कम एक कॉल ने एक call ट्रेस संदेश उत्पन्न किया (जो कि फ़ंक्शन मिलान विनिर्देशन से मेल खाता {message, false} था , और एक क्रिया नहीं थी)।

{trace, Pid, return_from, {M, F, Arity}, ReturnValue}

जब निर्दिष्ट फ़ंक्शन से Pid रिटर्न । यह ट्रेस संदेश भेजा जाता है यदि ध्वज सेट किया गया है, और फ़ंक्शन में एक या एक्शन के साथ मैच विनिर्देश है। call return_trace exception_trace

{trace, Pid, exception_from, {M, F, Arity}, {Class, Value}}

जब अपवाद के कारण निर्दिष्ट फ़ंक्शन से Pid बाहर निकलता है। यह ट्रेस संदेश भेजा जाता है यदि ध्वज सेट किया गया है, और फ़ंक्शन में कार्रवाई के साथ एक मैच विनिर्देश है। call exception_trace

{trace, Pid, spawn, Pid2, {M, F, Args}}

जब एंट्री पॉइंट के रूप में निर्दिष्ट फ़ंक्शन कॉल के साथ Pid एक नई प्रक्रिया शुरू Pid2 होती है।

Args तर्क सूची माना जाता है, लेकिन यदि स्पोन त्रुटिपूर्ण है तो कोई भी शब्द हो सकता है।

{trace, Pid, spawned, Pid2, {M, F, Args}}

जब प्रवेश बिंदु के रूप में निर्दिष्ट फ़ंक्शन कॉल के साथ Pid प्रक्रिया द्वारा उत्पन्न किया Pid2 जाता है।

Args तर्क सूची माना जाता है, लेकिन यदि स्पोन त्रुटिपूर्ण है तो कोई भी शब्द हो सकता है।

{trace, Pid, exit, Reason}

जब Pid कारण के साथ बाहर निकलता है Reason

{trace, PidPort, register, RegName}

जब PidPort नाम RegName पंजीकृत हो जाता है ।

{trace, PidPort, unregister, RegName}

जब PidPort नाम RegName अपंजीकृत हो जाता है । यह स्वचालित रूप से किया जाता है जब एक पंजीकृत प्रक्रिया या पोर्ट बाहर निकलता है।

{trace, Pid, link, Pid2}

जब Pid एक प्रक्रिया के लिए लिंक Pid2

{trace, Pid, unlink, Pid2}

जब Pid एक प्रक्रिया से लिंक हटाता है Pid2

{trace, PidPort, getting_linked, Pid2}

जब PidPort एक प्रक्रिया से जुड़ा हुआ है Pid2

{trace, PidPort, getting_unlinked, Pid2}

जब PidPort एक प्रक्रिया से अनलिंक हो जाता है Pid2

{trace, Pid, exit, Reason}

जब Pid कारण के साथ बाहर निकलता है Reason

{trace, Port, open, Pid, Driver}

जब रनिंग के साथ Pid एक नया पोर्ट खोलता है । Port Driver

Driver एक परमाणु के रूप में चालक का नाम है।

{trace, Port, closed, Reason}

जब Port साथ बंद कर देता है Reason

{trace, Pid, in | in_exiting, {M, F, Arity} | 0}

कब Pid चलना है? प्रक्रिया फ़ंक्शन में चलती है {M, F, Arity} । कुछ दुर्लभ अवसरों पर, वर्तमान फ़ंक्शन निर्धारित नहीं किया जा सकता है, फिर अंतिम तत्व है 0

{trace, Pid, out | out_exiting | out_exited, {M, F, Arity} | 0}

जब Pid शेड्यूल किया गया है। यह फंक्शन {M, F, Arity} फंक्शन में चल रहा था। कुछ दुर्लभ अवसरों पर, वर्तमान फ़ंक्शन निर्धारित नहीं किया जा सकता है, फिर अंतिम तत्व है 0

{trace, Port, in, Command | 0}

कब Port चलना है? Command पहली बात यह है कि पोर्ट निष्पादित करेगा, यह अनुसूचित होने से पहले कई कमांड चला सकता है। कुछ दुर्लभ अवसरों पर, वर्तमान फ़ंक्शन निर्धारित नहीं किया जा सकता है, फिर अंतिम तत्व है 0

संभव आदेशों हैं call , close , command , connect , control , flush , info , link , open , और unlink

{trace, Port, out, Command | 0}

जब Port शेड्यूल किया गया है। आखिरी कमांड रन था Command । कुछ दुर्लभ अवसरों पर, वर्तमान फ़ंक्शन निर्धारित नहीं किया जा सकता है, फिर अंतिम तत्व है 0 Command के रूप में एक ही आदेश शामिल कर सकते हैं in

{trace, Pid, gc_minor_start, Info}

भेजा गया जब एक युवा कचरा संग्रह शुरू होने वाला है। Info दो-तत्व ट्यूपल्स की एक सूची है, जहां पहला तत्व एक कुंजी है, और दूसरा मूल्य है। टुपल्स के किसी भी आदेश पर निर्भर न करें। निम्नलिखित कुंजियाँ परिभाषित की गई हैं:

heap_size
ढेर के प्रयुक्त भाग का आकार।
heap_block_size
मेमोरी ब्लॉक का आकार ढेर और स्टैक के भंडारण के लिए उपयोग किया जाता है।
old_heap_size
पुराने ढेर के प्रयुक्त भाग का आकार।
old_heap_block_size
पुराने ढेर को संग्रहीत करने के लिए उपयोग किए जाने वाले मेमोरी ब्लॉक का आकार।
stack_size
ढेर का आकार।
recent_size
पिछले कचरा संग्रहण से बचे हुए डेटा का आकार।
mbuf_size
प्रक्रिया से जुड़े संदेश बफ़र्स का संयुक्त आकार।
bin_vheap_size
प्रक्रिया के ढेर से संदर्भित अद्वितीय ऑफ-हीप बायनेरिज़ का कुल आकार।
bin_vheap_block_size
कचरा संग्रह करने से पहले बायनेरिज़ का कुल आकार वर्चुअल हीप में अनुमति देता है।
bin_old_vheap_size
प्रक्रिया के पुराने ढेर से संदर्भित अद्वितीय ऑफ-हीप बायनेरिज़ का कुल आकार।
bin_old_vheap_block_size
कचरा संग्रह करने से पहले बायनेरिज़ का कुल आकार वर्चुअल पुराने ढेर में अनुमति देता है।

सभी आकार शब्दों में हैं।

{trace, Pid, gc_max_heap_size, Info}

जब process_flag(max_heap_size,Size) कचरा संग्रहण के दौरान पहुंचा जाता है तो भेजा जाता है। Info संदेश में उसी तरह की सूची सम्‍मिलित है gc_start , लेकिन आकार उन आकारों को दर्शाते हैं, जिन max_heap_size तक पहुंच बनाई जा सकती है।

{trace, Pid, gc_minor_end, Info}

भेजा गया जब युवा कचरा संग्रह समाप्त हो गया है। Info संदेश में उसी तरह की सूची शामिल है gc_minor_start , लेकिन आकार कचरा संग्रह के बाद नए आकारों को दर्शाते हैं।

{trace, Pid, gc_major_start, Info}

भेजा गया जब फुलस्टेप कचरा संग्रह शुरू होने वाला है। Info संदेश में उसी तरह की सूची है जैसे कि gc_minor_start

{trace, Pid, gc_major_end, Info}

फुलस्टेप कचरा संग्रह समाप्त होने पर भेजा गया। Info संदेश में उसी तरह की सूची gc_minor_start सम्‍मिलित है, लेकिन फुलसेप कचरा संग्रह के बाद आकार नए आकार को दर्शाता है।

यदि अनुरेखण प्रक्रिया / पोर्ट मर जाता है या अनुरेखक मॉड्यूल वापस आ जाता है remove , तो झंडे चुपचाप हटा दिए जाते हैं।

प्रत्येक प्रक्रिया को केवल एक ट्रेसर द्वारा पता लगाया जा सकता है। इसलिए, पहले से ही ट्रेस प्रक्रिया विफल करने का प्रयास विफल।

एक संख्या लौटाती है जो मिलान वाली प्रक्रियाओं की संख्या को दर्शाती है PidPortSpec । यदि PidPortSpec एक प्रक्रिया पहचानकर्ता है, तो रिटर्न वैल्यू है 1 । यदि PidPortSpec है , all या existing वापसी मूल्य चल रही प्रक्रियाओं की संख्या है। यदि PidPortSpec है new , तो रिटर्न वैल्यू है 0

विफलता: badarg यदि निर्दिष्ट तर्क समर्थित नहीं हैं। उदाहरण के लिए, cpu_timestamp सभी प्लेटफार्मों पर समर्थित नहीं है।

erlang: ट्रेस_डेलीवरड (ट्रेस) -> रेफ

प्रकार

सिस्टम में अन्य घटनाओं की तुलना में ट्रेस संदेशों की डिलीवरी ( या erlang:trace/3 , द्वारा उत्पन्न ) समय-रेखा पर अस्वीकृत है। यदि आप जानते हैं कि इसके निष्पादन में कुछ विशिष्ट बिंदु बीत चुके हैं, और आप जानना चाहते हैं कि इस बिंदु तक की घटनाओं के अनुरूप कम से कम सभी ट्रेस संदेश ट्रैसर तक पहुंच गए हैं, तो उपयोग करें । seq_trace(3) erlang:system_profile/2 Tracee erlang:trace_delivered(Tracee)

जब यह गारंटी दी जाती है कि सभी ट्रेस संदेश ट्रैसर को उस बिंदु Tracee तक पहुंचा दिए जाते हैं जो कॉल करने के समय तक पहुंच जाता है erlang:trace_delivered(Tracee) , तब कॉल करने वाले को एक {trace_delivered, Tracee, Ref} संदेश भेजा जाता है erlang:trace_delivered(Tracee)

ध्यान दें कि संदेश का अर्थ trace_delivered यह नहीं है कि ट्रेस संदेश वितरित किए गए हैं। इसके बजाय इसका तात्पर्य है कि वितरित किए जाने वाले सभी ट्रेस संदेश वितरित किए गए हैं। यह त्रुटि नहीं है यदि Tracee नहीं है, और किसी के द्वारा पता नहीं लगाया गया है, लेकिन यदि यह मामला है, तो संदेश आने पर कोई ट्रेस संदेश नहीं दिया गया trace_delivered है।

ध्यान दें कि Tracee वर्तमान में या पहले उसी नोड पर मौजूदा प्रक्रिया का उल्लेख करना चाहिए जिस पर कॉल करने वाले का erlang:trace_delivered(Tracee) निवास होता है। विशेष Tracee परमाणु all सभी प्रक्रियाओं को दर्शाता है जो वर्तमान में नोड में पता लगाया जाता है।

जब एक साथ उपयोग किया जाता है Tracer Module , तो ट्रेस कॉलबैक में भेजे गए किसी भी संदेश को संदेश भेजने से पहले उसके प्राप्तकर्ता तक पहुंचने की गारंटी trace_delivered दी जाती है।

उदाहरण: प्रक्रिया A है Tracee , पोर्ट B ट्रेसर है और प्रक्रिया C पोर्ट के मालिक है B C बंद करने के लिए चाहता है B जब A बाहर निकलता है। यह सुनिश्चित करें कि ट्रेस छोटा कर दिया जाता है, C कॉल कर सकते हैं erlang:trace_delivered(A) जब A बाहर निकलता है, और संदेश के लिए प्रतीक्षा {trace_delivered, A, Ref} बंद करने से पहले B

असफलता: badarg यदि Tracee एक नोड पर एक प्रक्रिया (मृत या जीवित) का उल्लेख नहीं किया जाता है, जिस पर कॉल करने वाले का erlang:trace_delivered(Tracee) निवास होता है।

erlang: ट्रेस_इनफो (PidPortFuncEvent, Item) -> Res

प्रकार

Xim $ 1 ’का अनुमान | '$ 2' | '$ 3' | ...

रिटर्न एक पोर्ट, प्रक्रिया, फ़ंक्शन या ईवेंट के बारे में जानकारी का पता लगाता है।

एक बंदरगाह या प्रक्रिया के बारे में जानकारी प्राप्त करने के , PidPortFuncEvent एक प्रक्रिया पहचानकर्ता (पीआईडी), बंदरगाह पहचानकर्ता, या परमाणुओं में से एक माना है new , new_processes या new_ports । परमाणु new या new_processes इसका मतलब है कि बनाई जाने वाली प्रक्रियाओं के लिए डिफ़ॉल्ट ट्रेस स्थिति वापस आ गई है। परमाणु का new_ports अर्थ है कि बनाए जाने वाले बंदरगाहों के लिए डिफ़ॉल्ट ट्रेस स्थिति वापस आ गई है।

Item बंदरगाहों और प्रक्रियाओं के लिए मान्य :

flags

इस प्रक्रिया के लिए किस तरह के निशान सक्षम हैं, यह दर्शाता है कि परमाणुओं की एक सूची देता है। : यदि कोई निशान सक्षम होते हैं, और एक या निम्नलिखित परमाणुओं के अधिक अगर निशान सक्षम हैं, सूची खाली है send , 'receive' , set_on_spawn , call , return_to , procs , ports , set_on_first_spawn , set_on_link , running , running_procs , running_ports , silent , exiting , monotonic_timestamp , strict_monotonic_timestamp , garbage_collection , timestamp , और arity । आदेश मनमाना है।

tracer

इस प्रक्रिया का पता लगाने वाले अनुरेखक मॉड्यूल और अनुरेखक राज्य युक्त प्रक्रिया, पोर्ट, या टुपल के लिए पहचानकर्ता लौटाता है। यदि इस प्रक्रिया का पता नहीं लगाया जाता है, तो रिटर्न वैल्यू है []

किसी फ़ंक्शन के बारे में जानकारी प्राप्त करने के लिए , PidPortFuncEvent तीन-तत्व टपल {Module, Function, Arity} या परमाणु होना है on_load । किसी भी वाइल्डकार्ड की अनुमति नहीं है। undefined यदि फ़ंक्शन मौजूद नहीं है, या false फ़ंक्शन का पता नहीं है, तो लौटाता है। यदि PidPortFuncEvent है on_load , तो दी गई जानकारी कोड के लिए डिफ़ॉल्ट मान को संदर्भित करती है जिसे लोड किया जाएगा।

Item कार्यों के लिए मान्य :

traced

रिटर्न global अगर यह समारोह, वैश्विक समारोह कॉल पर पता लगाया है local कि अगर यह समारोह स्थानीय समारोह कॉल पर पता लगाया है (जो है, स्थानीय और वैश्विक फ़ंक्शन कॉल), और false स्थानीय या वैश्विक फ़ंक्शन कॉल का पता नहीं कर रहे हैं।

match_spec

इस फ़ंक्शन के लिए मैच विनिर्देश लौटाता है, अगर इसमें एक है। यदि फ़ंक्शन स्थानीय या विश्व स्तर पर पता लगाया गया है, लेकिन कोई मिलान विनिर्देश परिभाषित नहीं है, तो लौटा मूल्य है []

meta

इस फ़ंक्शन के लिए मेटा-ट्रेसर ट्रैसर प्रक्रिया, पोर्ट या ट्रेस मॉड्यूल लौटाता है, यदि यह एक है। यदि फ़ंक्शन मेटा-ट्रेस नहीं है, तो लौटाया गया मान है false । यदि फ़ंक्शन मेटा-ट्रेस किया गया है, लेकिन एक बार पता चला है कि ट्रेसर प्रक्रिया अमान्य है, तो लौटा मूल्य है []

meta_match_spec

इस फ़ंक्शन के लिए मेटा-ट्रेस मैच विनिर्देश लौटाता है, अगर इसमें एक है। यदि फ़ंक्शन मेटा-ट्रेस किया गया है, लेकिन कोई मिलान विनिर्देश परिभाषित नहीं है, तो लौटा हुआ मान है []

call_count

कॉल true फ़ंक्शन on_load ट्रेसिंग सक्रिय है, तो इस फ़ंक्शन के लिए या छद्म फ़ंक्शन के लिए कॉल गणना मान लौटाता है। अन्यथा false वापस कर दिया जाता है।

यह भी देखें erlang:trace_pattern/3

call_time

कॉल true फ़ंक्शन on_load ट्रेसिंग सक्रिय है, तो इस फ़ंक्शन के लिए या छद्म फ़ंक्शन के लिए कॉल समय मान देता है। अन्यथा false वापस कर दिया जाता है। कॉल समय मान लौटा, [{Pid, Count, S, Us}] प्रत्येक प्रक्रिया की एक सूची है जिसने फ़ंक्शन और इसके विशिष्ट काउंटरों को निष्पादित किया है।

यह भी देखें erlang:trace_pattern/3

all

एक सूची देता है जिसमें {Item, Value} अन्य सभी वस्तुओं के लिए टुपल्स होते हैं, या false इस फ़ंक्शन के लिए कोई ट्रेसिंग सक्रिय होने पर वापस नहीं आता है।

किसी घटना के बारे में जानकारी प्राप्त करना , PidPortFuncEvent परमाणुओं में से एक होना send या है 'receive'

Item घटनाओं के लिए एक मान्य मौजूद है:

match_spec

इस घटना के लिए मैच विनिर्देश लौटाता है, अगर इसमें एक है, या true यदि कोई मैच विनिर्देश निर्धारित नहीं किया गया है।

वापसी मूल्य {Item, Value} , जहां Value मांगी गई जानकारी है जैसा कि पहले बताया गया है। यदि एक मृत प्रक्रिया के लिए एक पीआईडी ​​निर्दिष्ट किया गया था, या एक गैर-मौजूदा फ़ंक्शन का नाम Value है undefined

erlang: ट्रेस_पाटन (MFA, माचिस) -> पूर्णांक ()> = 0

प्रकार

Xim $ 1 ’का अनुमान | '$ 2' | '$ 3' | ...

उसी के रूप में erlang:trace_pattern/3 , पिछड़े संगतता के लिए बनाए रखा।

erlang: ट्रेस_पाटन्ट (MFA :: सेंड, माचिस, फ्लैगलिस्ट :: []) ->
पूर्णांक ()> = 0

प्रकार

Xim $ 1 ’का अनुमान | '$ 2' | '$ 3' | ...

संदेश भेजने के लिए ट्रेस पैटर्न सेट करता है । ट्रेस ध्वज को एक या अधिक प्रक्रियाओं के erlang:trace/3 लिए सेट करने के लिए संयुक्त होना चाहिए send । डिफ़ॉल्ट रूप से send ट्रेस की गई प्रक्रियाओं से भेजे गए सभी संदेशों का पता लगाया जाता है। संदेश सामग्री, प्रेषक और / या रिसीवर, उपयोग के आधार पर ट्रेस भेजें घटनाओं को सीमित करने के लिए उपयोग करें erlang:trace_pattern/3

तर्क MatchSpec निम्नलिखित रूप ले सकता है:

MatchSpecList

मैच विनिर्देशों की एक सूची। मिलान सूची पर किया जाता है [Receiver, Msg] Receiver रिसीवर की प्रक्रिया या पोर्ट पहचान Msg है और संदेश शब्द है। भेजने की प्रक्रिया के पिड को गार्ड फ़ंक्शन के साथ एक्सेस किया जा सकता है self/0 । एक खाली सूची के रूप में ही है true । अधिक जानकारी के लिए, Match Specifications in Erlang उपयोगकर्ता मार्गदर्शिका में अनुभाग देखें ।

true

सभी भेजे गए संदेशों (ट्रेस की गई send प्रक्रियाओं से) के लिए अनुरेखण सक्षम करता है । किसी भी मैच विनिर्देश को हटा दिया जाता है। यह डिफ़ॉल्ट है

false

सभी भेजे गए संदेशों के लिए अनुरेखण अक्षम करता है। किसी भी मैच विनिर्देश को हटा दिया जाता है।

तर्क अनुरेखण के लिए FlagList होना चाहिए []

वापसी मूल्य हमेशा होता है 1

उदाहरण:

केवल एक विशिष्ट प्रक्रिया के लिए संदेश ट्रेस करें Pid :

> erlang:trace_pattern(send, [{[Pid, '_'],[],[]}], []).
1

केवल मिलान वाले संदेश ट्रेस करें {reply, _} :

> erlang:trace_pattern(send, [{['_', {reply,'_'}],[],[]}], []).
1

केवल प्रेषक को भेजे गए संदेश ट्रेस करें:

> erlang:trace_pattern(send, [{['$1', '_'],[{'=:=','$1',{self}}],[]}], []).
1

केवल अन्य नोड्स को भेजे गए संदेश ट्रेस करें:

> erlang:trace_pattern(send, [{['$1', '_'],[{'=/=',{node,'$1'},{node}}],[]}], []).
1
ध्यान दें

send ट्रेस के लिए एक मैच विनिर्देश को छोड़कर सभी गार्ड और बॉडी फ़ंक्शन का उपयोग कर सकते हैं caller

erlang: ट्रेस_पाटन्ट (MFA :: 'प्राप्त', माचिस, फ्लैगलिस्ट :: []) ->
पूर्णांक ()> = 0

प्रकार

Xim $ 1 ’का अनुमान | '$ 2' | '$ 3' | ...

संदेश प्राप्त करने के लिए ट्रेस पैटर्न सेट करता है । ट्रेस ध्वज को एक या अधिक प्रक्रियाओं के erlang:trace/3 लिए सेट करने के लिए संयुक्त होना चाहिए 'receive' । डिफ़ॉल्ट रूप से 'receive' ट्रेस की गई प्रक्रियाओं द्वारा प्राप्त सभी संदेशों का पता लगाया जाता है। संदेश सामग्री, प्रेषक और / या रिसीवर, उपयोग के आधार पर ट्रेस प्राप्त घटनाओं को सीमित करने के लिए उपयोग करें erlang:trace_pattern/3

तर्क MatchSpec निम्नलिखित रूप ले सकता है:

MatchSpecList

मैच विनिर्देशों की एक सूची। मिलान सूची पर किया जाता है [Node, Sender, Msg] Node प्रेषक का नोड नाम है। यदि प्रेषक ज्ञात नहीं है (जो दूरस्थ प्रेषकों के लिए मामला हो सकता है) Sender तो प्रेषक या परमाणु की प्रक्रिया या पोर्ट पहचान है undefined Msg संदेश शब्द है। प्राप्त करने की प्रक्रिया के पिड को गार्ड फ़ंक्शन के साथ एक्सेस किया जा सकता है self/0 । एक खाली सूची के रूप में ही है true । अधिक जानकारी के लिए, Match Specifications in Erlang उपयोगकर्ता मार्गदर्शिका में अनुभाग देखें ।

true

सभी प्राप्त संदेशों (ट्रेस की गई 'receive' प्रक्रियाओं) के लिए अनुरेखण सक्षम करता है । किसी भी मैच विनिर्देश को हटा दिया जाता है। यह डिफ़ॉल्ट है

false

सभी प्राप्त संदेशों के लिए अनुरेखण अक्षम करता है। किसी भी मैच विनिर्देश को हटा दिया जाता है।

तर्क अनुरेखण प्राप्त करने के लिए FlagList होना चाहिए []

वापसी मूल्य हमेशा होता है 1

उदाहरण:

केवल एक विशिष्ट प्रक्रिया से संदेश ट्रेस करें Pid :

> erlang:trace_pattern('receive', [{['_',Pid, '_'],[],[]}], []).
1

केवल मिलान वाले संदेश ट्रेस करें {reply, _} :

> erlang:trace_pattern('receive', [{['_','_', {reply,'_'}],[],[]}], []).
1

केवल अन्य नोड्स से संदेश ट्रेस करें:

> erlang:trace_pattern('receive', [{['$1', '_', '_'],[{'=/=','$1',{node}}],[]}], []).
1
ध्यान दें

के लिए एक मैच विनिर्देश 'receive' का पता लगाने के अलावा सभी गार्ड और शरीर के कार्यों का उपयोग कर सकते caller , is_seq_trace , get_seq_token , set_seq_token , enable_trace , disable_trace , trace , silent , और process_dump

erlang: ट्रेस_पाटन (MFA, माचिस, फ्लैगलिस्ट) ->
पूर्णांक ()> = 0

प्रकार

Xim $ 1 ’का अनुमान | '$ 2' | '$ 3' | ...

सक्षम या अक्षम कॉल ट्रेसिंग को एक या अधिक फ़ंक्शन के लिए। ट्रेस ध्वज को एक या अधिक प्रक्रियाओं के erlang:trace/3 लिए सेट करने के लिए संयुक्त होना चाहिए call

वैचारिक रूप से, कॉल ट्रेसिंग निम्नानुसार काम करती है। Erlang वर्चुअल मशीन के अंदर, प्रक्रियाओं का एक सेट और फ़ंक्शन का एक सेट का पता लगाया जाना है। यदि कोई ट्रेस प्रक्रिया किसी ट्रेस किए गए फ़ंक्शन को कॉल करती है, तो ट्रेस कार्रवाई की जाती है। नहीं तो कुछ नहीं होता।

ट्रेस की गई प्रक्रियाओं के सेट में एक या एक से अधिक प्रक्रियाओं को जोड़ने या हटाने के लिए, उपयोग करें erlang:trace/3

ट्रेस किए गए फ़ंक्शंस के सेट में फ़ंक्शंस जोड़ने या हटाने के लिए, उपयोग करें erlang:trace_pattern/3

बीआईएफ erlang:trace_pattern/3 एक समारोह में मैच विनिर्देशों को भी जोड़ सकता है। एक मैच विनिर्देश में एक पैटर्न शामिल होता है जिसे फ़ंक्शन तर्क से मेल खाना चाहिए, एक गार्ड अभिव्यक्ति जो कि मूल्यांकन करना चाहिए true , और एक प्रदर्शन किया जाना चाहिए। डिफ़ॉल्ट कार्रवाई ट्रेस संदेश भेजने के लिए है। यदि पैटर्न मेल नहीं खाता है या गार्ड विफल रहता है, तो कार्रवाई निष्पादित नहीं होती है।

तर्क MFA एक टपल होना है, जैसे कि {Module, Function, Arity} , या परमाणु on_load (नीचे वर्णित)। यह किसी फ़ंक्शन (या किसी मॉड्यूल में BIF) के लिए मॉड्यूल, फ़ंक्शन और एरीटी हो सकता है। परमाणु '_' को वाइल्डकार्ड के रूप में निम्न में से किसी भी तरीके से इस्तेमाल किया जा सकता है:

{Module,Function,'_'}

Function मॉड्यूल में नामित किसी भी धमनी के सभी कार्य Module

{Module,'_','_'}

मॉड्यूल में सभी कार्य Module

{'_','_','_'}

सभी लोड किए गए मॉड्यूल में सभी कार्य।

अन्य संयोजनों, जैसे {Module,'_',Arity} , की अनुमति नहीं है। स्थानीय फ़ंक्शन वाइल्डकार्ड से तभी मेल खाते हैं यदि विकल्प local में है FlagList

यदि तर्क MFA परमाणु है on_load , तो मैच विनिर्देश और ध्वज सूची उन सभी मॉड्यूल पर उपयोग की जाती है जो नए लोड किए गए हैं।

तर्क MatchSpec निम्नलिखित रूप ले सकता है:

false

मिलान कार्यों के लिए अनुरेखण अक्षम करता है। किसी भी मैच विनिर्देश को हटा दिया जाता है।

true

मिलान कार्यों के लिए अनुरेखण सक्षम करता है। किसी भी मैच विनिर्देश को हटा दिया जाता है।

MatchSpecList

मैच विनिर्देशों की एक सूची। एक खाली सूची के बराबर है true । मैच विनिर्देशों के विवरण के लिए, Match Specifications in Erlang उपयोगकर्ता की मार्गदर्शिका में अनुभाग देखें ।

restart

के लिए FlagList विकल्पों call_count और call_time : मौजूदा काउंटर पुन: प्रारंभ होता। व्यवहार अन्य FlagList विकल्पों के लिए अपरिभाषित है ।

pause

के लिए FlagList विकल्पों call_count और call_time : मौजूदा काउंटरों रुक जाता है। व्यवहार अन्य FlagList विकल्पों के लिए अपरिभाषित है ।

पैरामीटर FlagList विकल्पों की एक सूची है। निम्नलिखित वैध विकल्प हैं:

global

वैश्विक फ़ंक्शन कॉल के लिए कॉल ट्रेसिंग चालू या बंद करता है (अर्थात, स्पष्ट रूप से मॉड्यूल निर्दिष्ट करता है)। केवल निर्यात किए गए फ़ंक्शन मेल खाते हैं और केवल वैश्विक कॉल ट्रेस संदेश उत्पन्न करते हैं। यह डिफ़ॉल्ट है

local

सभी प्रकार के फ़ंक्शन कॉल के लिए कॉल ट्रेसिंग चालू या बंद करना। ट्रेस संदेश भेजे जाते हैं जब भी निर्दिष्ट कार्यों में से किसी को भी बुलाया जाता है, भले ही वे कैसे कहे जाएं। यदि ध्वज return_to प्रक्रिया के लिए सेट किया गया है, return_to तो यह संदेश तब भी भेजा जाता है जब यह फ़ंक्शन इसके कॉलर पर वापस आ जाता है।

meta | {meta, Pid} | {meta, TracerModule, TracerState}

सभी प्रकार के फ़ंक्शन कॉल के लिए मेटा-ट्रेसिंग चालू या बंद करता है। जब भी निर्दिष्ट कार्यों में से कोई भी कॉल किया जाता है, तो ट्रेस संदेश ट्रैसर को भेजे जाते हैं। यदि कोई ट्रेसर निर्दिष्ट नहीं है, self() तो उसे डिफ़ॉल्ट ट्रेसर प्रक्रिया के रूप में उपयोग किया जाता है।

मेटा-ट्रेसिंग सभी प्रक्रियाओं का पता लगाता है और इसके द्वारा निर्धारित प्रक्रिया ट्रेस झंडे की परवाह नहीं करता है erlang:trace/3 , ट्रेस झंडे इसके बजाय तय किए जाते हैं [call, timestamp]

मैच स्पेसिफिकेशन फ़ंक्शन {return_trace} मेटा-ट्रेस के साथ काम करता है और अपने ट्रेस मैसेज को उसी ट्रेसर पर भेजता है।

call_count

सभी प्रकार के फ़ंक्शन कॉल के लिए प्रारंभ ( MatchSpec == true ) या स्टॉप्स ( MatchSpec == false ) कॉल काउंटिंग। प्रत्येक फ़ंक्शन के लिए, किसी भी प्रक्रिया में फ़ंक्शन को कॉल करने पर एक काउंटर बढ़ाया जाता है। कोई प्रक्रिया ट्रेस झंडे को सक्रिय करने की आवश्यकता नहीं है।

यदि कॉल काउंट ट्रेसिंग पहले से ही चालू है, तो गिनती शून्य से पुनः आरंभ हो जाती है। चल रहे काउंटरों को रोकने के लिए, का उपयोग करें MatchSpec == pause । रुके हुए और चल रहे काउंटरों को शून्य से फिर से शुरू किया जा सकता है MatchSpec == restart

काउंटर मान पढ़ने के लिए, का उपयोग करें erlang:trace_info/2

call_time

सभी प्रकार के फ़ंक्शन कॉल के लिए प्रारंभ ( MatchSpec == true ) या स्टॉप ( MatchSpec == false ) कॉल टाइम ट्रेसिंग। प्रत्येक फ़ंक्शन के लिए, फ़ंक्शन को कॉल करने पर एक काउंटर बढ़ा दिया जाता है। फ़ंक्शन में बिताया गया समय दो अन्य काउंटर, सेकंड और माइक्रोसेकंड में जमा होता है। प्रत्येक कॉल ट्रेस प्रक्रिया के लिए काउंटरों को संग्रहीत किया जाता है।

यदि कॉल टाइम ट्रेसिंग पहले से ही चालू है, तो गिनती और समय शून्य से पुनः आरंभ होता है। चल रहे काउंटरों को रोकने के लिए, का उपयोग करें MatchSpec == pause । रुके हुए और चल रहे काउंटरों को शून्य से फिर से शुरू किया जा सकता है MatchSpec == restart

काउंटर मान पढ़ने के लिए, का उपयोग करें erlang:trace_info/2

विकल्प global और local पारस्परिक रूप से अनन्य हैं, और global डिफ़ॉल्ट है (यदि कोई विकल्प निर्दिष्ट नहीं हैं)। विकल्प call_count और meta एक प्रकार की स्थानीय अनुरेखण करते हैं, और इसके साथ जोड़ा नहीं जा सकता global । एक समारोह विश्व स्तर पर या स्थानीय रूप से पता लगाया जा सकता है। यदि वैश्विक ट्रेसिंग फ़ंक्शन के एक सेट के लिए निर्दिष्ट की जाती है, तो स्थानीय फ़ंक्शन के मिलान सेट के लिए स्थानीय, मेटा, कॉल समय और कॉल काउंट ट्रेसिंग अक्षम है, और इसके विपरीत।

ट्रेस को अक्षम करते समय, विकल्प को फ़ंक्शन पर सेट किए गए ट्रेस के प्रकार से मेल खाना चाहिए। यही है, स्थानीय अनुरेखण को विकल्प के साथ अक्षम किया जाना चाहिए local और विकल्प global (या कोई विकल्प नहीं) के साथ वैश्विक अनुरेखण , और इसी तरह।

मैच विनिर्देश सूची का हिस्सा सीधे नहीं बदला जा सकता है। यदि किसी फ़ंक्शन का मिलान विनिर्देश है, तो इसे एक नए के साथ बदला जा सकता है। मौजूदा मिलान विनिर्देश को बदलने के लिए, मौजूदा मिलान विनिर्देश erlang:trace_info/2 को पुनः प्राप्त करने के लिए BIF का उपयोग करें ।

तर्क मिलान कार्यों की संख्या लौटाता है MFA । यह शून्य है यदि कोई भी मेल नहीं खाता है।

ट्रंक (संख्या) -> पूर्णांक ()

प्रकार

Number उदाहरण के लिए, काटकर एक पूर्णांक लौटाता है :

> trunc(5.5).
5

गार्ड परीक्षण में अनुमति है।

tuple_size (Tuple) -> पूर्णांक ()> = 0

प्रकार

एक पूर्णांक देता है जो Tuple उदाहरण के लिए तत्वों की संख्या है :

> tuple_size({morni, mulle, bwange}).
3

गार्ड परीक्षण में अनुमति है।

tuple_to_list (Tuple) -> [अवधि ()]

प्रकार

के अनुरूप सूची देता है Tuple Tuple किसी भी Erlang शब्द हो सकते हैं। उदाहरण:

> tuple_to_list({share, {'Ericsson_B', 163}}).
[share,{'Ericsson_B',163}]
erlang: unique_integer () -> पूर्णांक ()

उत्पन्न करता है और रिटर्न करता है integer unique on current runtime system instance । बुला के समान erlang:unique_integer([monotonic])

erlang: unique_integer (संशोधक सूची) -> पूर्णांक ()

प्रकार

उत्पन्न करता है और रिटर्न करता है integer unique on current runtime system instance । पूर्णांक इस अर्थ में अद्वितीय है कि यह बीआईएफ, संशोधक के एक ही सेट का उपयोग करके, एक ही पूर्णांक को वर्तमान रनटाइम सिस्टम उदाहरण पर एक से अधिक बार वापस नहीं करता है। प्रत्येक पूर्णांक मान बेशक अन्य साधनों द्वारा निर्मित किया जा सकता है।

डिफ़ॉल्ट रूप से, जब [] इसे पास किया जाता है ModifierList , तो नकारात्मक और सकारात्मक दोनों पूर्णांक वापस आ सकते हैं। यह उन पूर्णांकों की श्रेणी का उपयोग करने के लिए है, जिन्हें अधिक से अधिक मेमोरी आवंटन की आवश्यकता नहीं है। डिफ़ॉल्ट रूप से लौटे पूर्णांकों को भी केवल विशिष्ट होने की गारंटी दी जाती है, अर्थात, कोई भी पूर्णांक पूर्णांक पूर्णांक पूर्णांक से छोटा या बड़ा हो सकता है।

Modifier रों:

सकारात्मक

केवल सकारात्मक पूर्णांक देता है।

ध्यान दें कि positive संशोधक को पास करने से आपको ढेर आवंटित पूर्णांक (bignums) जल्दी मिलेंगे।

monotonic

strictly monotonically increasing निर्माण समय के लिए पूर्णांक देता है । यही है, पूर्णांक लौटा हमेशा चालू क्रम प्रणाली उदाहरण पर पहले दिए गए पूर्णांकों से बड़ा होता है।

रनटाइम सिस्टम उदाहरण पर घटनाओं के बीच क्रम निर्धारित करने के लिए इन मानों का उपयोग किया जा सकता है। यही है, अगर दोनों X = erlang:unique_integer([monotonic]) और Y = erlang:unique_integer([monotonic]) एक ही रनटाइम सिस्टम उदाहरण पर अलग-अलग प्रक्रियाओं (या एक ही प्रक्रिया) द्वारा निष्पादित किए जाते हैं और X < Y , हम जानते हैं कि X पहले बनाया गया था Y

चेतावनी

सख्ती से नीरस रूप से बढ़ते मूल्य उत्पन्न करने के लिए स्वाभाविक रूप से काफी महंगे हैं और खराब तरीके से तराजू। ऐसा इसलिए है क्योंकि मूल्यों को CPU कोर के बीच सिंक्रनाइज़ करने की आवश्यकता है। यही है, monotonic संशोधक को पास न करें जब तक कि आपको वास्तव में कड़ाई से नीरस रूप से बढ़ते मूल्यों की आवश्यकता न हो।

सभी मान्य Modifier एस को जोड़ा जा सकता है। बार-बार (मान्य) की अनदेखी Modifier की ModifierList जाती है।

ध्यान दें

पूर्णांकों का सेट द्वारा लौटाए erlang:unique_integer/1 के विभिन्न सेट का उपयोग कर Modifier रों ओवरलैप जाएगा । उदाहरण के लिए, कॉल करके unique_integer([monotonic]) , और unique_integer([positive, monotonic]) बार-बार, आप अंततः कुछ पूर्णांक देखेंगे जो दोनों कॉल द्वारा वापस किए जाते हैं।

विफलताएं:

badarg
अगर ModifierList एक उचित सूची नहीं है।
badarg
यदि Modifier एक वैध संशोधक नहीं है।
एरलैंग: यूनिवर्सलटाइम () -> डेटटाइम

प्रकार

{{Year, Month, Day}, {Hour, Minute, Second}} यदि अंतर्निहित OS द्वारा समर्थित रूप में यूनिवर्सल टाइम कोऑर्डिनेट (UTC) के अनुसार वर्तमान दिनांक और समय देता है । अन्यथा erlang:universaltime() के बराबर है erlang:localtime() । उदाहरण:

> erlang:universaltime().
{{1996,11,6},{14,18,43}}
erlang: Universaltime_to_localtime (यूनिवर्सलटाइम) -> स्थानीय समय

प्रकार

यदि यूनिवर्सल {{Year, Month, Day}, {Hour, Minute, Second}} OS द्वारा समर्थित है तो यूनिवर्सल टाइम कोऑर्डिनेट (UTC) दिनांक और समय को स्थानीय दिनांक और समय में रूपांतरित करता है । अन्यथा कोई रूपांतरण नहीं किया जाता है, और Universaltime वापस कर दिया जाता है। उदाहरण:

> erlang:universaltime_to_localtime({{1996,11,6},{14,18,43}}).
{{1996,11,7},{15,18,43}}

विफलता: badarg यदि Universaltime अमान्य दिनांक और समय को दर्शाता है।

अनलिंक (आईडी) -> सच

प्रकार

लिंक को हटाता है, अगर कॉलिंग प्रक्रिया और द्वारा संदर्भित प्रक्रिया या पोर्ट के बीच एक है Id

लौटता है true और विफल नहीं होता है, भले ही कोई लिंक न हो Id या Id मौजूद न हो।

एक बार unlink(Id) वापस आ जाने के बाद , यह गारंटी दी जाती है कि Id भविष्य में कॉल करने वाले और इकाई के बीच लिंक का कॉलर पर कोई प्रभाव न पड़े (जब तक कि लिंक फिर से सेटअप न हो)। यदि कॉलर बाहर निकल रहा है, {'EXIT', Id, _} तो कॉल से पहले कॉल करने वाले के संदेश कतार में लिंक से एक संदेश रखा जा सकता है।

ध्यान दें कि {'EXIT', Id, _} संदेश लिंक का परिणाम हो सकता है, लेकिन Id कॉलिंग का परिणाम भी हो सकता है exit/2 । इसलिए, कॉल के बाद बाहर निकलते समय, संदेश की कतार को साफ करना उचित हो सकता unlink(Id) है:

unlink(Id),
receive
    {'EXIT', Id, _} ->
        true
after 0 ->
        true
end
ध्यान दें

इससे पहले कि एरलांग / ओटीपी आर 11 बी (ईआरटीएस 5.5) unlink/1 पूरी तरह से अतुल्यकालिक रूप से व्यवहार करता है, अर्थात, लिंक तब तक सक्रिय था जब तक "अनलिंक सिग्नल" लिंक इकाई तक नहीं पहुंच गया। इसका एक अवांछनीय प्रभाव था, जैसा कि आप कभी नहीं जान सकते कि आपको कब लिंक से प्रभावित नहीं होने की गारंटी दी गई थी।

वर्तमान व्यवहार को दो संयुक्त अभियानों के रूप में देखा जा सकता है: अतुल्यकालिक रूप से लिंक किए गए इकाई को "अनलिंक सिग्नल" भेजें और लिंक के भविष्य के परिणामों को अनदेखा करें।

अपंजीकृत (RegName) -> सत्य

प्रकार

RegName उदाहरण के लिए, किसी प्रक्रिया पहचानकर्ता या पोर्ट पहचानकर्ता से संबद्ध पंजीकृत नाम को हटाता है :

> unregister(db).
true

उपयोगकर्ताओं को सलाह दी जाती है कि वे सिस्टम प्रक्रियाओं को अपंजीकृत न करें।

विफलता: badarg यदि RegName कोई पंजीकृत नाम नहीं है।

whereis (RegName) -> पिड () | port () | अपरिभाषित

प्रकार

पंजीकृत नाम के साथ प्रक्रिया पहचानकर्ता या पोर्ट पहचानकर्ता लौटाता है RegName undefined यदि नाम पंजीकृत नहीं है तो लौटाता है । उदाहरण:

> whereis(db).
<0.43.0>
erlang: उपज () -> सच

स्वेच्छा से अन्य प्रक्रियाओं (यदि कोई हो) को निष्पादित करने का मौका मिलता है। इस फ़ंक्शन का उपयोग करना समान है receive after 1 -> ok end , सिवाय इसके कि yield() तेज है।

चेतावनी

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

Original text