Will the currently-being-designed message-passing concurrency be supported
between OS processes? Or only OS threads supported is planned?
Others may be probably interested in: light-weight threads, cooperative
concurrency
and communication through network? If the implementation is not planned for
initial release, is it planned for foreseeable future?
Thank you for answer.

Will the currently-being-designed message-passing concurrency be
supported between OS processes? Or only OS threads supported is planned?
Others may be probably interested in: light-weight threads, cooperative
concurrency and communication through network? If the implementation is
not planned for initial release, is it planned for foreseeable future?
Thank you for answer.

The goal is for it to work seamlessly between threads, processes or even
different computers.
--
Simen

Will the currently-being-designed message-passing concurrency be
supported between OS processes? Or only OS threads supported is planned?
Others may be probably interested in: light-weight threads, cooperative
concurrency and communication through network? If the implementation is
not planned for initial release, is it planned for foreseeable future?
Thank you for answer.

The goal is for it to work seamlessly between threads, processes or even
different computers.
--
Simen

Will the currently-being-designed message-passing concurrency be supported
between OS processes? Or only OS threads supported is planned?

Both, but initially only between threads.

Others may be probably interested in: light-weight threads, cooperative
concurrency
and communication through network? If the implementation is not planned for
initial release, is it planned for foreseeable future?

User threads (fibers) may be used at some point, and this should be invisible
to the user. Network messaging will definitely be added. These won't be
available in the initial release however.

Will the currently-being-designed message-passing concurrency be
supported between OS processes? Or only OS threads supported is planned?
Others may be probably interested in: light-weight threads, cooperative
concurrency and communication through network? If the implementation is
not planned for initial release, is it planned for foreseeable future?
Thank you for answer.

Right now we don't have time to focus on more than inter-thread
communication. Sean and I had a pow-wow last week and decided we don't
have the resources to address more than that. But definitely the design
has an eye on future extensibility, of which inter-process communication
is an obvious extension.
Andrei

Will the currently-being-designed message-passing concurrency be
supported between OS processes? Or only OS threads supported is
planned? Others may be probably interested in: light-weight threads,
cooperative concurrency and communication through network? If the
implementation is not planned for initial release, is it planned for
foreseeable future?
Thank you for answer.

communication. Sean and I had a pow-wow last week and decided we don't
have the resources to address more than that. But definitely the design
has an eye on future extensibility, of which inter-process communication
is an obvious extension.
Andrei

I haven't seen a single mention of what kind of algoritms can be solved
efficiently with this framework. Is it good for parallel algorithms like
parallel matrix multiplication, merge sort, producer/consumer problems,
serving web pages, rendering fractals, blitting images, parallel parsing,
handling RPC or GUIs?

Must mean you haven't looked. Message passing is a well-understood paradigm.
Andrei

Will the currently-being-designed message-passing concurrency be
supported between OS processes? Or only OS threads supported is
planned? Others may be probably interested in: light-weight threads,
cooperative concurrency and communication through network? If the
implementation is not planned for initial release, is it planned for
foreseeable future?
Thank you for answer.

communication. Sean and I had a pow-wow last week and decided we don't
have the resources to address more than that. But definitely the
design has an eye on future extensibility, of which inter-process
communication is an obvious extension.
Andrei

You gotta be kidding. If the message passing framework abstracts away all
information about communication latencies, how can one tune the algorithm
to take advantage of data locality? I have both knowledge of theoretic
models such as Hoare's CSP and practical systems such as MPI and MPI-2. I
just want to know how your system maps 2+ processes to data parallel SSE
instructions when data locality is very high, to threads with shared
memory when the locality is a bit lower and how it groups execution into
larger chunks on NUMA and multi-computer clusters. Does it handle this
all internally when you run a foreach loop or do you have more fine-
grained control over data?

SIMD-style data-parallel computation is not something we are currently
addressing explicitly in the type system and in the standard library.
You are welcome to contribute such APIs though; your level of knowledge
definitely makes you the most appropriate potential contributor.
Andrei

Will the currently-being-designed message-passing concurrency be
supported between OS processes? Or only OS threads supported is
planned? Others may be probably interested in: light-weight threads,
cooperative concurrency and communication through network? If the
implementation is not planned for initial release, is it planned for
foreseeable future?
Thank you for answer.

Right now we don't have time to focus on more than inter-thread
communication. Sean and I had a pow-wow last week and decided we don't
have the resources to address more than that. But definitely the design
has an eye on future extensibility, of which inter-process communication
is an obvious extension.
Andrei

I haven't seen a single mention of what kind of algoritms can be solved
efficiently with this framework. Is it good for parallel algorithms like
parallel matrix multiplication, merge sort, producer/consumer problems,
serving web pages, rendering fractals, blitting images, parallel parsing,
handling RPC or GUIs?

Will the currently-being-designed message-passing concurrency be
supported between OS processes? Or only OS threads supported is
planned? Others may be probably interested in: light-weight threads,
cooperative concurrency and communication through network? If the
implementation is not planned for initial release, is it planned for
foreseeable future?
Thank you for answer.

communication. Sean and I had a pow-wow last week and decided we don't
have the resources to address more than that. But definitely the
design has an eye on future extensibility, of which inter-process
communication is an obvious extension.
Andrei

I haven't seen a single mention of what kind of algoritms can be solved
efficiently with this framework. Is it good for parallel algorithms
like parallel matrix multiplication, merge sort, producer/consumer
problems, serving web pages, rendering fractals, blitting images,
parallel parsing, handling RPC or GUIs?

Must mean you haven't looked. Message passing is a well-understood
paradigm.

You gotta be kidding. If the message passing framework abstracts away all
information about communication latencies, how can one tune the algorithm
to take advantage of data locality? I have both knowledge of theoretic
models such as Hoare's CSP and practical systems such as MPI and MPI-2. I
just want to know how your system maps 2+ processes to data parallel SSE
instructions when data locality is very high, to threads with shared
memory when the locality is a bit lower and how it groups execution into
larger chunks on NUMA and multi-computer clusters. Does it handle this
all internally when you run a foreach loop or do you have more fine-
grained control over data?