Commits

Dmitry Grebeniuk  committed fe5f4f3

init

  • Participants

Comments (0)

Files changed (2)

+~$
+^_build/
+\.(byte|native)$
+(*
+Параллельный* велосипед.
+
+  * -- уточнение: пока не параллельный, а просто message passing.
+
+  Текущая цель: обеспечить типизированный message passing поверх
+lwt (в частности; и любого монадного интерфейса ввода-вывода в общем
+случае), позволяющий:
+  - порождать легковесные процессы, принимающие сообщения одного типа,
+    отправляющие сообщения другого типа,
+  - осуществлять ввод-вывод внутри процесса,
+  - завершать текущий процесс,
+  - слать широковещательные сообщения группе процессов,
+
+  В планах на будущее (реализовать сразу после реализации локальных
+процессов, но обязательно держать это в голове при планировании):
+  - прозрачно порождать настоящие процессы ОС для распараллеливания
+    вычислений между ядрами процессора и хостами, с целью
+    максимально-полной утилизации процессорной мощности, памяти,
+    дискового ввода-вывода (в том числе учитывая блокирующий
+    ввод-вывод).
+
+  В относительно-далёком будущем понадобятся:
+  - пользовательская сериализация
+  - передача данных через shared memory где можно
+  - что-то наподобие work stealing queues.  Как тупой аналог -- рабочие,
+    слушающие общий tcp/ip-сокет и берущие задания, отправляемые туда
+    через connect+send+close (то есть, кто из рабочих свободен, тот и
+    берёт задание.  Не совсем wsq, так как требует синхронного действия
+    как рабочего, так и мастера, в отличие от wsq, где обворовываемый
+    в неведении.).
+*)
+
+
+(* Принятые обозначения:
+   'i -- тип принимаемых сообщений,
+   'o -- тип отправляемых сообщений. *)
+
+type process_group 'i 'o;
+
+type process 'i 'o;
+
+(* диспетчер сообщений -- то, что содержит пользовательский код,
+   но обёрнуто в абстрактный тип. *)
+
+type dispatcher 'i 'o;
+(*   = ~context 'i 'o ->  ('i -> IO unit)  ?
+     where context 'i 'o =
+        < ! ’o2 . send : process 'o2 'i -> 'i -> IO unit
+              (* полиморфность по 'o2 достигается тем, что он не должен
+                 использоваться в теле send *)
+        ; me : process 'i 'o
+        ; my_group : process_group 'i 'o
+        >   *)
+
+(* IO 'a читать как Lwt.t 'a. *)
+
+(*
+для синхронных серверов предусмотреть что-то похожее на
+gen_server:handler_call, по прикидкам упрощающее дело:
+
+value gen_server : (gen_server_context 'i 'o -> ('i * caller) -> IO unit)
+   -> process_server 'i 'o
+
+     where gen_server_context 'i 'o =
+        < ! i2 . reply: caller 'o 'i2 -> 'o -> IO unit
+        ; me : process 'i 'o
+        ; ..   (* возможно send тоже надо, т.е. сделать это
+                  подтипом основного context;
+                  вроде бы, в эрланге это таки есть -- можно отвечать
+                  на сообщения не по порядку.  Или reply_to,
+                  оборачивающую ответ как надо. *)
+        >
+     and caller 'o 'i = (process 'o 'i * tag)
+
+  возможно стоит возвращать не process 'i 'o, а его подтип,
+  к которому будет позволено применять
+
+value call : process_server 'i 'o -> 'i -> IO 'o;
+*)
+
+
+(* обеспечить мономорфность получающегося типа, чтобы в случае top-level
+   значений были конкретные типы. *)
+value create_process_group : unit -> process_group 'i 'o;
+value create_process : process_group 'i 'o -> dispatcher 'i 'o
+  -> process 'i 'o;
+
+(* нужно конкретно для частной задачи, поэтому не уверен в ценности:
+   функция шлёт сообщения группе и дожидается ответа каждого из процессов
+   этой группы, затем возвращает массив ответов *)
+
+value send_msg_group_gather_all : process_group 'i 'o -> 'i -> res (array 'o);
+
+(* если будет call, то можно будет выразить это как отсылку call-запросов
+  и приём call-ответов *)
+
+(* ответы на сообщения будут производиться через передаваемый
+  в функцию контекст, где будут функции send для простых процессов
+  и reply для call-подобных. *)