From f95ffbbf6d0590c97904e043a97bfeb2ca0b08b3 Mon Sep 17 00:00:00 2001 From: Hoya-kim <1203play@gmail.com> Date: Thu, 16 Mar 2023 03:01:14 +0900 Subject: [PATCH 1/6] docs: Add md about Object.values and Object.entries --- src/ko/Object.values-Object.entries.md | 37 ++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 src/ko/Object.values-Object.entries.md diff --git a/src/ko/Object.values-Object.entries.md b/src/ko/Object.values-Object.entries.md new file mode 100644 index 0000000..b526aba --- /dev/null +++ b/src/ko/Object.values-Object.entries.md @@ -0,0 +1,37 @@ +# Object.values / Object.entries + +`Object.values`/`Object.entries` 에 대한 ECMAScript 제안, 사양 및 참조 구현 + +[@ljharb](https://github.com/ljharb) 가 초안을 작성한 사양. + +이 제안은 현재 [프로세스](https://tc39.github.io/process-document/) 의 [stage 4](https://github.com/tc39/ecma262) 에 있으며 ES 2017에 포함될 예정입니다. + +지정된 TC39 검토자: @wycats @littledan @rwaldron + +[Engine Implementations(구현 엔진)](https://github.com/tc39/proposal-object-values-entries/issues/10) + +## 이전 토론 + +- [TC39 회의록](https://github.com/rwaldron/tc39-notes/blob/c61f48cea5f2339a1ec65ca89827c8cff170779b/es6/2014-04/apr-9.md#51-objectentries-objectvalues) +- esdiscuss: +- [https://esdiscuss.org/topic/object-entries-object-values](https://esdiscuss.org/topic/object-entries-object-values) +- [https://esdiscuss.org/topic/es6-iteration-over-object-values](https://esdiscuss.org/topic/es6-iteration-over-object-values) +- [https://esdiscuss.org/topic/object-values-and-or-object-foreach](https://esdiscuss.org/topic/object-values-and-or-object-foreach) -> [https://esdiscuss.org/topic/iteration-was-re-object-values-and-or-object-foreach](https://esdiscuss.org/topic/iteration-was-re-object-values-and-or-object-foreach) +- [https://esdiscuss.org/topic/object-entries-in-2015](https://esdiscuss.org/topic/object-entries-in-2015) +- [https://esdiscuss.org/topic/providing-object-iterators-beyond-just-object-keys](https://esdiscuss.org/topic/providing-object-iterators-beyond-just-object-keys) + +## 이론적 근거 + +객체를 해시 필터로 사용할 때와 같이, 객체의 자체 값(values)을 필요로 하는 경우가 많습니다. 그리고 lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. + +반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. + +우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. + +## 사양 + +사양을 [마크다운 형식](https://github.com/tc39/proposal-object-values-entries/blob/main/spec.md) 이나 [HTML 문서](http://tc39.github.io/proposal-object-values-entries/)로 볼 수 있습니다. 참고: `Object.{keys,values,entries}`각 함수가 동일한 키 순서를 공유하도록 약간의 사양 리팩토링이 있었습니다. + +## Iterators 또는 배열? + +`Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. \ No newline at end of file From 51f6e966c0a713469834e534b675c1543c2f26d4 Mon Sep 17 00:00:00 2001 From: Hoya-kim <1203play@gmail.com> Date: Thu, 16 Mar 2023 03:14:22 +0900 Subject: [PATCH 2/6] =?UTF-8?q?docs:=20=ED=8F=B4=EB=A6=AC=ED=95=84=20?= =?UTF-8?q?=EB=A7=81=ED=81=AC=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/ko/Object.values-Object.entries.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/ko/Object.values-Object.entries.md b/src/ko/Object.values-Object.entries.md index b526aba..27c05c1 100644 --- a/src/ko/Object.values-Object.entries.md +++ b/src/ko/Object.values-Object.entries.md @@ -1,7 +1,7 @@ # Object.values / Object.entries `Object.values`/`Object.entries` 에 대한 ECMAScript 제안, 사양 및 참조 구현 - + [@ljharb](https://github.com/ljharb) 가 초안을 작성한 사양. 이 제안은 현재 [프로세스](https://tc39.github.io/process-document/) 의 [stage 4](https://github.com/tc39/ecma262) 에 있으며 ES 2017에 포함될 예정입니다. @@ -34,4 +34,14 @@ ## Iterators 또는 배열? -`Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. \ No newline at end of file +`Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. + +## 폴리필 + +[폴리필 링크](https://github.com/tc39/proposal-object-values-entries/blob/main/polyfill.js) + +아래 네 개의 문법이 선행되어야 합니다. +- `Array.prototype.reduce` +- `Object.prototype.propertyIsEnumerable` +- `Array.prototype.concat` +- `Reflect.ownKeys` \ No newline at end of file From fd8e13cf4b4366399c7c03f025e2681fcc835101 Mon Sep 17 00:00:00 2001 From: Hoya-kim <1203play@gmail.com> Date: Tue, 28 Mar 2023 21:52:40 +0900 Subject: [PATCH 3/6] =?UTF-8?q?docs:=20=EC=98=A4=ED=83=88=EC=9E=90=20?= =?UTF-8?q?=EC=88=98=EC=A0=95=20=EB=B0=8F=20=EB=88=84=EB=9D=BD=EB=B6=80?= =?UTF-8?q?=EB=B6=84=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/ko/Object.values-Object.entries.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ko/Object.values-Object.entries.md b/src/ko/Object.values-Object.entries.md index 27c05c1..6d0f81d 100644 --- a/src/ko/Object.values-Object.entries.md +++ b/src/ko/Object.values-Object.entries.md @@ -24,7 +24,7 @@ 객체를 해시 필터로 사용할 때와 같이, 객체의 자체 값(values)을 필요로 하는 경우가 많습니다. 그리고 lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. -반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. +순회 또는 직렬화를 위해 객체에서 키/값 쌍의 배열(사양에서의 '항목(entries)')을 얻는 것 또한 유용합니다. `Map` 생성자가 순회 가능한 `entries`와 관련된 `entries` 반복자(`WeakMap`도 생성자에서 순회 가능한 `entries`을 허용함)를 수용함에 따라, `entries` 배열을 `new Map`으로 전달하여 일반 객체를 `Map`으로 빠르게 변환하고자 할 때 매우 강력해집니다. 우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. From 7159d67fe0991cb98d84fccbbfd71fe9463f7771 Mon Sep 17 00:00:00 2001 From: Hoya-kim <1203play@gmail.com> Date: Tue, 28 Mar 2023 22:06:32 +0900 Subject: [PATCH 4/6] =?UTF-8?q?docs:=20=EB=A6=AC=EB=B7=B0=20=EB=B0=98?= =?UTF-8?q?=EC=98=81,=20=EB=B2=88=EC=97=AD=20=EC=88=98=EC=A0=95=20?= =?UTF-8?q?=EB=B0=8F=20=EC=98=A4=ED=83=88=EC=9E=90=20=EC=88=98=EC=A0=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/ko/Object.values-Object.entries.md | 28 +++++++++----------------- 1 file changed, 9 insertions(+), 19 deletions(-) diff --git a/src/ko/Object.values-Object.entries.md b/src/ko/Object.values-Object.entries.md index 6d0f81d..25a69f8 100644 --- a/src/ko/Object.values-Object.entries.md +++ b/src/ko/Object.values-Object.entries.md @@ -1,14 +1,14 @@ -# Object.values / Object.entries +# [Object.values](https://github.com/es-shims/Object.values) / [Object.entries](https://github.com/es-shims/Object.entries) -`Object.values`/`Object.entries` 에 대한 ECMAScript 제안, 사양 및 참조 구현 +`Object.values`/`Object.entries` 에 대한 ECMAScript 제안, 사양 및 참조 구현. [@ljharb](https://github.com/ljharb) 가 초안을 작성한 사양. -이 제안은 현재 [프로세스](https://tc39.github.io/process-document/) 의 [stage 4](https://github.com/tc39/ecma262) 에 있으며 ES 2017에 포함될 예정입니다. +본 제안서는 [전체과정](https://tc39.github.io/process-document/)에서 [4단계](https://github.com/tc39/ecma262)에 있으며 ES2017에 포함될 예정입니다. 지정된 TC39 검토자: @wycats @littledan @rwaldron -[Engine Implementations(구현 엔진)](https://github.com/tc39/proposal-object-values-entries/issues/10) +[Engine Implementations(엔진 구현)](https://github.com/tc39/proposal-object-values-entries/issues/10) ## 이전 토론 @@ -22,26 +22,16 @@ ## 이론적 근거 -객체를 해시 필터로 사용할 때와 같이, 객체의 자체 값(values)을 필요로 하는 경우가 많습니다. 그리고 lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. +예를 들어, 객체를 해시 필터로 사용할 때와 같이 객체의 자체 값이 필요한 매우 일반적인 사용 사례입니다. lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. 순회 또는 직렬화를 위해 객체에서 키/값 쌍의 배열(사양에서의 '항목(entries)')을 얻는 것 또한 유용합니다. `Map` 생성자가 순회 가능한 `entries`와 관련된 `entries` 반복자(`WeakMap`도 생성자에서 순회 가능한 `entries`을 허용함)를 수용함에 따라, `entries` 배열을 `new Map`으로 전달하여 일반 객체를 `Map`으로 빠르게 변환하고자 할 때 매우 강력해집니다. -우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. +우리는 이미 자신의 키 배열을 반환하는 `Object.keys`와 `Map`/`Set`/`Array`에서 일치하는 `keys`/`values`/`entries` 반복자의 세 쌍을 반환하는 선례를 가지고 있습니다. 이와 같이, es-discuss에 대한 토론과 적어도 하나의 이전 TC39 회의에서 이 제안서는 ECMAScript에 `Object.values` 및 `Object.entries`를 추가하려고 합니다. `Object.keys`와 마찬가지로, 이 두 메서드는 배열을 반환합니다. 이 배열들의 순서는 `Object.keys` 순서와 정확히 일치하여, 세 결과 배열의 모든 인덱스가 객체의 동일한 키, 값 또는 항목을 반영합니다. ## 사양 -사양을 [마크다운 형식](https://github.com/tc39/proposal-object-values-entries/blob/main/spec.md) 이나 [HTML 문서](http://tc39.github.io/proposal-object-values-entries/)로 볼 수 있습니다. 참고: `Object.{keys,values,entries}`각 함수가 동일한 키 순서를 공유하도록 약간의 사양 리팩토링이 있었습니다. +사양을 [마크다운 형식](https://github.com/tc39/proposal-object-values-entries/blob/main/spec.md)으로 보거나, [HTML 문서](http://tc39.github.io/proposal-object-values-entries/)로 렌더링할 수 있습니다. 참고: `Object.{keys,values,entries}`가 동일한 키 순서를 공유하도록 약간의 사양 리팩토링이 있었습니다. -## Iterators 또는 배열? +## 반복자 또는 배열? -`Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. - -## 폴리필 - -[폴리필 링크](https://github.com/tc39/proposal-object-values-entries/blob/main/polyfill.js) - -아래 네 개의 문법이 선행되어야 합니다. -- `Array.prototype.reduce` -- `Object.prototype.propertyIsEnumerable` -- `Array.prototype.concat` -- `Reflect.ownKeys` \ No newline at end of file +`Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 반복자에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열-값 및 심볼-값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(키, 값, 항목)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 반복자를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 순회 가능합니다. From d0c478a300180045335f53e27314dd053c58b39b Mon Sep 17 00:00:00 2001 From: Hoya-kim <1203play@gmail.com> Date: Tue, 28 Mar 2023 22:06:53 +0900 Subject: [PATCH 5/6] =?UTF-8?q?docs:=20=EC=9B=90=EB=AC=B8=20=EC=9D=B4?= =?UTF-8?q?=EC=99=B8=20=EB=B6=80=EB=B6=84,=20summary=EB=A1=9C=20=EB=B6=84?= =?UTF-8?q?=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/summary/Object.values-Object.entries.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 src/summary/Object.values-Object.entries.md diff --git a/src/summary/Object.values-Object.entries.md b/src/summary/Object.values-Object.entries.md new file mode 100644 index 0000000..dd3703b --- /dev/null +++ b/src/summary/Object.values-Object.entries.md @@ -0,0 +1,15 @@ +# 목차 + +1. **[폴리필](#폴리필)** + +--- + +## 폴리필 + +[폴리필 링크](https://github.com/tc39/proposal-object-values-entries/blob/main/polyfill.js) + +아래 네 개의 문법이 선행되어야 합니다. +- `Array.prototype.reduce` +- `Object.prototype.propertyIsEnumerable` +- `Array.prototype.concat` +- `Reflect.ownKeys` \ No newline at end of file From 6d0f046a355df8fa4a0ace580be8524f783889f4 Mon Sep 17 00:00:00 2001 From: Hoya-kim <1203play@gmail.com> Date: Fri, 7 Jul 2023 15:09:41 +0900 Subject: [PATCH 6/6] =?UTF-8?q?docs:=20shared=20memory=20=EB=B2=88?= =?UTF-8?q?=EC=97=AD=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/ko/ecmascript_sharedmem.md | 30 ++++ src/summary/ecmascript_sharedmem.md | 240 ++++++++++++++++++++++++++++ 2 files changed, 270 insertions(+) create mode 100644 src/ko/ecmascript_sharedmem.md create mode 100644 src/summary/ecmascript_sharedmem.md diff --git a/src/ko/ecmascript_sharedmem.md b/src/ko/ecmascript_sharedmem.md new file mode 100644 index 0000000..ea27a12 --- /dev/null +++ b/src/ko/ecmascript_sharedmem.md @@ -0,0 +1,30 @@ +# ecmascript_sharedmem + +이는 ECMAScript용 공유 메모리(Shared Memory) 및 아토믹(Atomic) 사양으로, ECMAScript 승인 과정에서 현재 4단계에 있는 제안서입니다. + +**중요 참고사항**: 2017년 2월부로 이 제안은 [ECMAScript 사양](https://tc39.github.io/ecma262/)으로 통합되었습니다. 버그 수정 및 발전사항은 해당 문서에서 발생하며, 현재 저장소의 산문은 점점 더 무관해질 것입니다. 버그가 발견되면 먼저 ECMAScript 사양을 확인하고 버그가 해당 버전에도 있다면 이 저장소가 아닌 [ecma262 버그 트래커](https://github.com/tc39/ecma262/issues)에 버그를 기록해주시기 바랍니다. + +## 문서 및 기타 자료 + +- [포맷된 사양](http://tc39.github.io/ecmascript_sharedmem/shmem.html) +- [DOM 지원 사양](http://tc39.github.io/ecmascript_sharedmem/dom_shmem.html) +- [asm.js 동반 사양](http://tc39.github.io/ecmascript_sharedmem/asmjs_shmem.html) +- [간단한 자습서 소개](https://github.com/tc39/proposal-ecmascript-sharedmem/blob/main/TUTORIAL.md) +- [데모 프로그램 및 기타 예제](https://github.com/tc39/proposal-ecmascript-sharedmem/blob/main/DEMOS.md) +- [자주 묻는 질문](https://github.com/tc39/proposal-ecmascript-sharedmem/blob/main/FAQ.md) +- [고수준의 설계 문제, 횡단관심사 문제, 보안 문제 등](https://github.com/tc39/proposal-ecmascript-sharedmem/blob/main/DISCUSSION.md) +- Ecma TC39에 제공되는 프레젠테이션용 슬라이드: + - [2015년 9월](https://github.com/tc39/ecmascript_sharedmem/blob/master/tc39/presentation-sept-2015.odp) + - [2016년 1월](https://github.com/tc39/ecmascript_sharedmem/blob/master/tc39/presentation-jan-2016.odp) + +## 구현 + +Firefox, Chrome 및 WebKit는 제안서의 프로토타입 구현과 함께 제공되며, 이들 대부분이 호환됩니다. + +- 이 기능은 Firefox Nightly에서 기본적으로 사용되며, Firefox 46부터는 Developer Edition, Aurora, Beta 및 Release 사용자가 `about:config`를 방문하여 `javascript.options.shared_memory` 옵션을 `true`로 설정할 수 있습니다. +- 이 기능은 Chrome에서 기본적으로 해제되어 있지만 명령줄 옵션 `--js-sys=--sys-shared-arraybuffer` 및 `--enable-blink-feature=SharedArrayBuffer`를 전달하여 활성화할 수 있습니다(Chrome 48에서 작동하는 것으로 알려져 있음) +- 이 기능은 STP 20 기준으로 WebKit Nightly 및 Safari Technology Preview에서 기본적으로 활성화됩니다. + +## 기타 + +사양의 소스는 tc39/ 하위 디렉터리에 있으며 포맷된 버전은 `format.sh` 스크립트로 생성됩니다. \ No newline at end of file diff --git a/src/summary/ecmascript_sharedmem.md b/src/summary/ecmascript_sharedmem.md new file mode 100644 index 0000000..6c02b0a --- /dev/null +++ b/src/summary/ecmascript_sharedmem.md @@ -0,0 +1,240 @@ +# 목차 + +1. **[TUTORIAL.md](#TUTORIAL.md)** + +# TUTORIAL.md + +## 공유 메모리 - 간단한 튜토리얼 + +### 동시 에이전트 + +브라우저 설정에서 공유 에이전트에 워커를 사용하는 것은 자연스러운 일입니다. 요약하자면 워커는 워커에서 실행할 스트립트의 URL을 `Worker` 객체에 할당하여 생성할 수 있습니다. + +```js +var w = new Worker('myworker.js'); +``` + +워커와 워커를 생성한 부모는 메시지 채널을 통해 통신합니다. 부모에서 `w.postMessage` 호출 시 워커에게 메시지를 보내고, 워커 객체의 핸들러는 메시지를 이벤트로 수신합니다. + +```js +w.postMessage('hi'); // send "hi" to the worker +w.onmessage = function (ev) { + console.log(ev.data); // prints "ho" +}; +``` + +한편, 워커에서는 전역 핸들러가 메시지를 이벤트로 수신하고 전역 `postMessage` 함수를 호출하면 메시지를 부모에게 다시 보냅니다. + +```js +onmessage = function (ev) { + console.log(ev.data); // prints "hi" + postMessage('ho'); // sends "ho" back to the creator +}; +``` + +문자열뿐만 아니라 많은 유형의 데이터가 채널을 통해 전송될 수 있으며, 대상에 올바른 타입과 구조로 도착합니다. + +### 공유 메모리 할당 및 공유 + +공유 메모리를 할당하려면 SharedArrayBuffer를 할당하기만 하면 됩니다. + +```js +var sab = new SharedArrayBuffer(1024); // 1KiB shared memory +``` + +부모는 표준 `postMessage` 메서드을 사용하여 워커에게 메모리를 전송하여 워커와 이 메모리를 공유할 수 있습니다 . + +```js +w.postMessage(sab); +``` + +작업자에서 이 개체는 이벤트의 데이터 속성으로 수신됩니다. + +```js +var sab; +onmessage = function (ev) { + sab = ev.data; // 1KiB shared memory, the same memory as in the parent +}; +``` + +메모리는 임의의 에이전트에서 생성한 후 다른 에이전트와 공유할 수 있으며 여러 에이전트 간에 동시에 공유할 수 있습니다. + +### 공유 메모리에 뷰 생성 + +SharedArrayBuffer는 공유되는 메모리를 제외하면 ArrayBuffer와 같으며 ArrayBuffer의 메모리와 동일한 방식으로 메모리에 접근합니다. 버퍼에 뷰를 생성한 다음 표준 배열 액세스 구문을 사용하여 뷰(view)를 통해 메모리에 액세스합니다. Int8Array에서 Float64Array까지 ArrayBuffer와 동일한 뷰 타입을 SharedArrayBuffer에 적용할 수 있습니다. + +공유 메모리의 부모가 해당 배열을 수정할 의도 없이 워커와 큰 소수 배열을 공유하려고 한다고 가정합니다. 메모리를 할당하고 채우고 보냅니다. + +```js +var sab = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT * 100000); // 100000 primes +var ia = new Int32Array(sab); // ia.length == 100000 +var primes = new PrimeGenerator(); +for (let i = 0; i < ia.length; i++) ia[i] = primes.next(); +w.postMessage(ia); +``` + +워커는 전송된 Int32Array를 수신합니다. + +```js +var ia; +onmessage = function (ev) { + ia = ev.data; // ia.length == 100000 + console.log(ia[37]); // prints 163, the 38th prime +}; +``` + +### 공유 메모리 업데이트 및 가시성 + +메모리가 실제로 공유되기 때문에 한 에이전트의 쓰기는 해당 메모리를 공유하는 다른 모든 에이전트에서 관찰됩니다. + +```js +console.log(ia[37]); // Prints 163 +ia[37] = 123456; +``` + +쓰기 작업을 실행한 에이전트에서 할당이 발생한 후, 잠시 후 변경 사항이 다른 에이전트에 표시됩니다. + +```js +console.log(ia[37]); // Prints 123456, maybe, eventually +``` + +공유 메모리의 가장 까다로운 측면 중 하나는 쓰기 작업이 한 에이전트에서 다른 에이전트로 전파되는 데 걸리는 시간을 알기 어렵다는 것입니다. CPU, 운영 체제, 브라우저 및 실제로 쓰기 및 읽기 시 시스템에서 발생하는 다른 모든 것을 포함하는 시스템의 매우 광범위한 정의에 대해 실제로 작업이 발생하는 속도는 시스템에 따라 다릅니다. + +사실, 추가 *동기화*가 없으면 위의 프로그램은 잘 정의되지 않습니다. (충돌하지는 않지만 읽기를 수행하는 에이전트는 163 및 123456 이외의 다른 값을 관찰할 수 있습니다. 이는 직관적이지 않지만 발생할 수 있습니다.) 동기화는 다음에 설명된 원자성 작업을 사용하여 구현됩니다. + +### 원자성 작업 + +`Atomics`이라고 불리는 새로운 전역 객체는 여러 가지 새로운 *원자성 작업*을 정적 메서드로 제공합니다. 원자성 작업은 여러 관련 용도로 사용됩니다. + +### 예측 가능한 값을 쓰고 읽기 + +원자 쓰기로 작성된 배열 요소의 원자 읽기는 쓰기 전에 셀에 있던 값 또는 쓰여진 값만 관찰합니다. + +위의 예에서 작성자가 원자 쓰기를 사용하는 경우: + +```js +console.log(ia[37]); // Prints 163, the 38th prime +Atomics.store(ia, 37, 123456); +``` + +그런 다음 값을 읽을 경우 값이 변경될 때까지 기다리기 위해 루프에서 원자 읽기를 사용할 수 있으며 일단 변경되면 예상대로 변경됩니다. + +```js +while (Atomics.load(ia, 37) == 163); +console.log(ia[37]); // Prints 123456 +``` + +#### 원자적 작업으로 순서 지정 + +원자적 읽기가 값을 관찰하면 기록기가 관찰된 쓰기를 수행하기 전에 수행한 다른 모든 쓰기(원자적이든 아니든)도 관찰 가능하다는 보장이 있습니다. + +그것이 사실이 아닐 수도 있다는 것은 직관적이지 않지만 일어날 수 있습니다. 작가가 다음과 같이 한다고 가정합니다. + +```js +ia[42] = 314159; // was 191 +ia[37] = 123456; // was 163 +``` + +다른 작업자가 이 두 값을 읽는다고 가정합니다. + +```js +console.log(ia[37]); +console.log(ia[42]); +``` + +판독기는 123456 및 191을 인쇄할 수 있지만 그렇게 되지 않아야 합니다. 그 이유는 쓰기가 컴파일러와 (더 자주) CPU에 의해 재정렬될 수 있기 때문입니다. + +원자성 연산은 프로그램에서 순서 포인트를 생성합니다. ia[37]이 원자적으로 작성되는 경우 원자 쓰기 이전에 수행된 모든 쓰기는 ia[37]에 대한 쓰기가 관찰되기 전까지 관찰 가능합니다. + +```js +ia[42] = 314159; // was 191 +Atomics.store(ia, 37, 123456); // was 163 +``` + +```js +while (Atomics.load(ia, 37) == 163); +console.log(ia[37]); // Will print 123456 +console.log(ia[42]); // Will print 314159 +``` + +(마찬가지로 읽기가 순서 없이 수행될 수 있습니다. 원자성 작업도 읽기 순서를 지정합니다.) + +#### 원자성 작업은 중단할 수 없습니다 + +원자적 읽기-수정-쓰기 작업은 수정된 값이 다시 기록될 때까지 다른 쓰기가 발생하지 않도록 보장합니다. + +두 에이전트가 증가해야 하는 ia[112]의 공유 메모리에 카운터가 있다고 가정합니다. 명백한 값으로 증가시키면 `ia[112]++`둘 다 동시에 그렇게 할 위험이 있으며 업데이트가 손실될 수 있습니다(그리고 결과 값이 쓰레기가 될 수 있음). 그 이유는 증분을 수행하기 위해 CPU가 값을 로드하고 여기에 1을 더한 다음 다시 저장해야 하기 때문입니다. 그 사이에 다른 CPU가 같은 일을 했을 수도 있습니다. + +대신 `Atomics.add(ia, 112, 1)`를 사용하면 경합이 발생하지 않도록 보장할 수 있습니다. 각 CPU는 중단되지 않고 개별적으로 로드, 추가 및 저장되며 카운터는 올바르게 업데이트됩니다. + +#### 원자적 작업 연산 + +다음 작업은 `array`가 Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array 또는 Uint32Array일 때 사용할 수 있습니다. + +| 연산 | 기능 | +| --------------------------------------------- | ----------------------------------------------------------------------------------------- | +| load(array, index) | array[index]의 값을 반환 | +| store(array, index, value) | array[index]에 값 저장, 반환 값 | +| compareExchange(array, index, oldval, newval) | array[index] == oldval이면 newval을 array[index]에 저장하고 array[index]의 이전 값을 반환 | +| exchange(array, index, value) | array[index]에 값을 저장하고 array[index]의 이전 값을 반환 | +| add(array, index, value) | array[index]에 값을 추가하고 array[index]의 이전 값을 반환 | +| sub(array, index, value) | array[index]에서 값을 빼고 array[index]의 이전 값을 반환 | +| and(array, index, value) | 논리곱 값을 array[index], array[index]의 이전 값 반환 | +| or(array, index, value) | 논리합 값을 array[index]로, array[index]의 이전 값을 반환 | +| xor(array, index, value) | 배타적 논리합 값을 array[index]로, array[index]의 이전 값을 반환 | + +### 작업이 일어나길 기다리기 + +위의 예에서 한 에이전트는 다른 에이전트가 값을 변경할 때까지 루프를 사용했습니다. 변경은 에이전트가 대기를 중단하고 다음에 해야 할 일을 계속 진행할 수 있다는 신호입니다. + +이러한 *회전 루프*는 대기 시간이 매우 짧지 않는 한 컴퓨터 시간을 잘못 사용합니다. 대신 대기 중인 에이전트는 스스로를 절전 모드로 전환할 수 있으며 대신 다른 에이전트에 의해 명시적으로 깨울 수 있습니다. Atomics 개체는 두 메서드 `wait` 및 `wake` 에서 이를 위한 기본 메커니즘을 제공합니다. + +이 예에서 쓰기 에이전트는 이제 다음을 수행합니다. + +```js +console.log(ia[37]); // Prints 163 +Atomics.store(ia, 37, 123456); +Atomics.wake(ia, 37, 1); +``` + +읽기 에이전트는 다음을 수행합니다. + +```js +Atomics.wait(ia, 37, 163); +console.log(ia[37]); // Prints 123456 +``` + +이것이 작동하는 방식은 일단 쓰기를 수행하면 쓰기 에이전트가 위치 ia[37]에서 잠자고 있는 한 에이전트를 깨우도록 요청한다는 것입니다. 한편, 읽기 에이전트는 ia[37]의 값이 여전히 163인 경우 잠자기를 요청합니다. 따라서 쓰기 에이전트가 이미 쓰기를 수행한 경우 읽기 에이전트는 계속 진행하고, 그렇지 않으면 잠자고 대기하며 깨어날 때까지 기다립니다. + +### 추상화 + +실제로 일부 공유 메모리 기능, 특히 `wait` 및 `wake`는 정확하고 효율적으로 사용하기 어려울 수 있습니다. 따라서 사용을 단순화하기 위해 이들 주위에 추상화(JavaScript에서)를 구축하는 것이 유용합니다. 예를 들어 데모에서 전통적인 뮤텍스와 조건 변수를 찾을 수 있습니다. 이는 간단한 원자 값의 컨테이너이며 업데이트 대기 기능이 내장된(그리고 효율적인) 소위 "동기적" 객체입니다. + +### 미묘함과 실용적인 조언 + +(추가 주제: 경쟁 조건, 교착 상태, flatjs?, 웹 API 및 공유 메모리.) + +#### 브라우저의 기본 스레드에서 차단 + +브라우저의 메인 스레드에서 대기하는 것에 대해 본질적으로 문제가 있는 것은 없습니다. `wait`는 웨이크업 플래그가 설정되기를 기다리는 루프와 동일한 의미를 갖습니다. 그러나 대기 시간이 짧을 것이라는 보장이 없는 한 그러한 대기를 피하고 대신 메인 스레드를 대신하여 작동하고 메시지 전달을 사용하여 메인 스레드와 통신하는 "마스터 워커"를 두는 것이 좋습니다. "마스터 워커"는 브라우저의 응답성에 영향을 주지 않고 무기한 기다릴 수 있습니다. + +해당 패턴의 변형은 마스터 워커가 필요하지 않지만 일부 조건이 충족될 때 마스터에게 메시지를 보내는 것에 대해 워커가 서로 조정하는 제어 구조입니다. 데모 섹션의 "비대칭 장벽"이 그러한 제어 구조입니다. + +이 사양은 브라우저가 `wait`를 기본 스레드에서 거부할 수 있도록 허용하며 대부분의 브라우저가 결국 그렇게 할 것으로 예상됩니다. `wait`가 거부된 경우 예외가 발생합니다. + +#### 원자적 액세스와 비원자적 액세스를 혼합하지 마십시오 + +원자적 액세스와 비원자적 액세스를 모두 사용하여 동일한 배열 요소에 안전하게 액세스하는 것이 확실히 가능하지만 일반적으로 제한된 상황에서만 가능합니다. 실제로 주어진 공유 배열 요소가 원자적으로 또는 비원자적으로 액세스되는 것이 가장 좋습니다. 원자적 요소는 동기화 변수 및 간단한 통신 채널로 사용되어야 하며, 비원자적 요소는 더 많은 양의 데이터에 사용될 수 있습니다. + +#### 공유 메모리 비용 + +SharedArrayBuffer는 얼마나 비쌉니까? 현재 Firefox 구현에서는 공유 메모리를 사용하는 가장 쉬운 방법이 몇 개의 여러 뷰를 사용하여 응용 프로그램에 의해 분할되는 상당히 큰 공유 개체입니다. (어떤 의미에서 이것은 에이전트 간에 공유 객체를 전송하는 것이 어색하기 때문에 자기 충족적 예언입니다) 다른 구현에서는 작은 객체(예: 공유 응용 프로그램 객체당 하나)의 사용을 장려하는 다른 전략을 선택할 수 있습니다. + +### 현재 구현에 대한 참고 사항(2016년 1월) + +Firefox와 Chrome은 모두 제안된 API를 구현합니다. + +- Firefox에서 API는 Nightly에서 기본적으로 활성화되며 Firefox 46부터는 에서 javascript.options.shared_memorytrue로 설정하여 Aurora, Developer Edition, Beta 및 Release에서 활성화할 수 있습니다 about:config. waitFirefox는 기본 스레드에서 거부합니다. +- Chrome에서 API는 기본적으로 꺼져 있으며 명령줄 옵션으로 활성화할 수 있습니다(문서화 예정). + +Firefox에는 기본적으로 20개로 설정된 작업자 수에 대한 도메인당 제한이 있습니다. 한도를 초과하면 도메인의 새 작업자가 생성되지만 시작되지 않은 상태로 유지됩니다. wait시작되지 않은 작업자에 있는 프로그램은 일반적으로 교착 상태가 됩니다. (아마도 제한은 WebWorkers 사양을 위반하는 것입니다. 이를 명확히 하는 것을 목표로 하는 이 WHATWG 버그를 참조하십시오 .)