[Top][All Lists]
[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
- Re: [Chicken-users] google summer of code, (continued)
- Re: [Chicken-users] google summer of code, Shawn Rutledge, 2008/03/05
- Re: [Chicken-users] google summer of code, Ivan Raikov, 2008/03/05
- Re: [Chicken-users] google summer of code, Alex Shinn, 2008/03/05
- Re: [Chicken-users] google summer of code, Ivan Raikov, 2008/03/05
- Re: [Chicken-users] google summer of code, Alaric Snell-Pym, 2008/03/06
- Re: [Chicken-users] google summer of code, Alex Shinn, 2008/03/06
- Re: [Chicken-users] google summer of code, felix winkelmann, 2008/03/07
- Re: [Chicken-users] google summer of code, Alaric Snell-Pym, 2008/03/10
- Re: [Chicken-users] google summer of code, Graham Fawcett, 2008/03/07
- Re: [Chicken-users] google summer of code, Ivan Raikov, 2008/03/07
- Re: [Chicken-users] google summer of code,
Graham Fawcett <=
- [Chicken-users] Re: Chicken MPI, Ivan Raikov, 2008/03/08
- [Chicken-users] Re: Chicken MPI, Graham Fawcett, 2008/03/08
- Re: [Chicken-users] google summer of code, felix winkelmann, 2008/03/10
- Re: [Chicken-users] google summer of code, Ivan Raikov, 2008/03/10
- Re: [Chicken-users] google summer of code, Felix Winkelmann, 2008/03/12
- Re: [Chicken-users] google summer of code, Ivan Raikov, 2008/03/12
- Re: [Chicken-users] google summer of code, Houman Zolfaghari, 2008/03/10
- Re: [Chicken-users] google summer of code, Tobia Conforto, 2008/03/11
- Re: [Chicken-users] google summer of code, Alaric Snell-Pym, 2008/03/10
- Re: [Chicken-users] google summer of code, Leonardo Valeri Manera, 2008/03/07