chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] google summer of code


From: Graham Fawcett
Subject: Re: [Chicken-users] google summer of code
Date: Fri, 7 Mar 2008 19:42:36 -0500

On Fri, Mar 7, 2008 at 6:48 PM, Ivan Raikov <address@hidden> wrote:
>
>  "Graham Fawcett" <address@hidden> writes:
>
>  > On reflection, I'd much rather see a really efficient IPC system like
>  > this, rather than having a native-threaded Chicken.
>
>   Try the MPI egg! (Yet another shameless plug, I know).

Not a shameless plug, IMO -- I had never really looked at MPI. Thanks!
For newbies like me, I'd love to see an MPI-for-dummies egg that
overlayed it with a simpler, familiar protocol (like mailbox).

>  > Other than for concurrent designs, I think there is a case for native
>  > threads when I/O is involved. I believe that GHC Haskell uses a
>  > separate native thread for handling I/O, but (unless you use forkIO)
>  > runs everything else in lightweight threads. Perhaps we could play a
>  > similar game, and spawn native threads as I/O custodians, managed
>  > under a very strict protocol that avoids GC contention and other
>  > concurrency issues. Perhaps one I/O thread and select/epoll is enough.
>
>   No, forkIO is normally for lightweight threads. forkOS explicitly
>  associates Haskell threads with native threads. See here for details:

D'oh, you're right, I got them backwards.

>   Concurrent Haskell is based on monadic processes: if you want to
>  have Haskell-like threads, first you need to provide support for
>  monads in the core of Chicken.

Well, my idea was slightly less grandiose. :-) I imagine that native
threads might be useable within a Chicken process, as long as code
running in those threads followed *very* restrictive guidelines. Most
notably they would not share data with the main (Chicken) thread
except through a proper message-passing interface. That would mean
that the native threads would *never* have access to any value in
Chicken's heap and stack -- data could only be copied across a
synchronized boundary. In this way, a native thread could perform
blocking I/O in isolation, passing 'packets' across the MPI boundary
to the Chicken process.

It's just a sketchy idea, Ivan, and not worth anyone's time unless it
would simplify certain blocking I/O and native-library scenarios.

Graham




reply via email to

[Prev in Thread] Current Thread [Next in Thread]