[Haskell-cafe] FFI and callbacks

Sebastian Sylvan sebastian.sylvan at gmail.com
Tue Jul 26 06:32:04 EDT 2005


On 7/26/05, Simon Marlow <simonmar at microsoft.com> wrote:
> On 25 July 2005 22:41, Sebastian Sylvan wrote:
> 
> > On 7/25/05, Simon Marlow <simonmar at microsoft.com> wrote:
> >> On 23 July 2005 03:38, Duncan Coutts wrote:
> >>
> >>> The problem then as John noted is that the main loop of these
> >>> toolkits block and so the other Haskell threads would not get a
> >>> chance to schedule. So the challenge is to give the Haskell threads
> >>> a chance to schedule.
> >>
> >> [ good description of the multi-threaded GUI problem deleted ]
> >>
> >> Thanks for describing the problem in detail, I understand it better
> >> now. I think it comes down to this conflict:
> >>
> >>  - you want to take advantage of the fact that GHC has lightweight
> >>    "green" threads in order to do multithreading within a single OS
> >> thread, but
> >>
> >>  - our "bound threads" design does not require the implementation
> >>    to support lightweight threads, and hence doesn't let the
> >>    programmer take advantage of them.
> >
> > Well how about not touching the "bound threads" design at all, but
> > modifying the lightweigh threads design to also include "forkIOHere"
> > (or something) which would produce a lightweight thread which is
> > always run in the "main" OS thread.
> 
> This is what Duncan was angling for, I think.  My point is that this
> requires the implementation to support lightweight threads, which is
> something we intentionally avoided in the bound threads design.
 
No it doesn't. If they don't support lightweight threads, they won't
have the forkIOHere function available.
I.e. leave it out of the bound threads design and just implement it as
a feature in the GHC lightweight threads system.

/S

-- 
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862


More information about the Haskell-Cafe mailing list