Re: [Chicken-users] google summer of code

[Graham Fawcett]

On Thu, Mar 6, 2008 at 6:27 AM, Alaric Snell-Pym
<address@hidden> wrote:

>  I wrote an efficient shared-memory lock-free queue system for a
>  client once. They own the copyright, but I would happily mentor a
>  student to build a somewhat more general and portable (this was
>  specific to a few platforms) version of it in C and wrap it in
>  chicken for lightweight interprocess goodness :-)

On reflection, I'd much rather see a really efficient IPC system like
this, rather than having a native-threaded Chicken. The overhead of a
trivial Chicken process is quite small, and multiple communicating
processes is much safer than a shared-everything threaded design.
Having a shared-memory version of remote-mailbox would be very useful:
if mailbox, remote-mailbox and sm-mailbox could share an API, we would
have a very powerful IPC abstraction.

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.

>  I'm also keen on a proper library/module system, though. I'd like to
>  be able to use multiple macro systems in the same source file, for a
>  start.

As long as I don't have to give up lowlevel macros, I'm happy. :-)

Graham