On Tue, Jul 13, 2010 at 4:26 PM, chromatic <[email protected]> wrote: > My preference is a message passing system with lightweight interpreters and > some sort of PMC proxy to coordinate data which must appear shared between > threads/processes.
I agree, lighter-weight interpreter objects would be nice. Chandon was talking about paring them down to be more light-weight, but I'll let him share the details of his plan once it's ready. > * low CPU overhead for creating/managing concurrent entities of execution > (avoid the cost of creating a new Perl 5 interpreter, for example) Agreed. The common case will likely be single-threaded systems, or systems which only use green threads, so data sharing becomes a very small issue. In these situations, we don't want to see a huge overhead tax placed on all accesses, since we don't need it. Some system which lazily applies synchronization mechanisms only when required would be nice (though probably difficult to implement) > * share as little as possible and that only explicitly (to avoid the C problem > of thread-unsafety by default) This seems like an argument that every shared PMC must be explicitly shared/synchronized or else it cannot be used in separate threads. That is, we would rather prefer no access to unsafe access. > * allow options for parallelism and concurrency (to permit building something > like Python's GIL or Perl 5's ithreads without dictating too much) I definitely don't think we want a huge angry GIL, but having a lock for write operations on global data (namespaces and the class cache come to mind) might be nice. I'm not sure how we can redo things to avoid locking these global items. > If possible, it'd be nice to avoid the problem that many dynamic languages run > into with C extensions, where wrapping a library that's not thread safe > dictates that the entire extension system needs a global lock. I agree with that too, though we end up placing much more burden on the extension developers. If we go this route, we're going to have to spend much more effort to make sure the concurrency portions of our extension API is very sane and very useable. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
