On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrote:
> On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg <[email protected]>
> wrote:
> > If thread-unsafe subroutines are called, then something like ithreads
> > might be used.
>
> For the love of $DEITY, let's please not repeat ithreads!
It's worth remembering that ithreads are far superior to the older
5005threads model, where multiple threads ran with an interpreter.
[Shudder]
It's also worth remembering that real O/S level threads are needed to
work asynchronously with third-party libraries that would block.
Database client libraries that don't offer async support are an
obvious example.
I definitely agree that threads should not be the dominant form of
concurrency, and I'm certainly no fan of working with O/S threads.
They do, however, have an important role and can't be ignored.
So I'd like to use this sub-thread to try to identify when lessons we
can learn from ithreads. My initial thoughts are:
- Don't clone a live interpreter.
Start a new thread with a fresh interpreter.
- Don't try to share mutable data or data structures.
Use message passing and serialization.
Tim.
