HGL with GHC in Win32

[Alastair Reid]

>> I guess the Win32 version has fallen behind.

> Yet in other aspects, the SOE version is ahead.. Would it be
> possible to resynch the various versions? 

A long-term goal is to refactor the code into a portable layer, a
layer which can be ported (i.e., a maze of ifdefs) and a
machine-dependent layer.  I'm not sure when I'll get to that - work,
my current ffi hacking and some personal stuff are consuming all my
time.

> Or, even better: once the various ffi implementations have settled
> down to the latest spec,

The CVS copy of Hugs implements the current spec.  (But works only on
Linux and (perhaps) Windows) at the moment and has a habit of changing
critical details of how you use it every other day at the moment...)

> and <dream>HOpenGL works with all Haskell implementations</dream>,
> perhaps HGL could be ported to HOpenGL - to eliminate all further
> portability issues (missing features under X, etc.)..

I think the basic HGL API would work on a lot of platforms.  I don't
know enough about HOpenGL to be sure but I think it's easier to
implement HGL on than X11 or Win32 were.

>> What really needs done though is to introduce a single semaphore to
>> control all access to all parts of the HGL data structures -
>> atomically accessing each part of the data structures doesn't
>> necessarily protect all the system invariants.

> I'll leave that to others:)

I see it as part of a complete rewrite of the system - adding
preemptive concurrency to a cooperatively-threaded program is very
hard to get right.

> Btw, you use yield before a potentially blocking call - would the
> latter run into the problems (default-configured) ghc has with
> blocking foreign calls (see multithreading support in the ghc
> commentary)?

The way HGL works is that an event comes in, triggers a lot of work
which eventually terminates, and then we block for another event. 
The idea of the yield is to make sure that all other work has
terminated before we make that blocking call to get the next event.

> Or is this what you referred to with GreenCard's safecode?

Looking a bit harder at it, it seems I was a bit confused...

The ffi distinguishes  3 levels of safety: 

  unsafe  = not reentrant, only calls RTS system calls from a very 
            restricted list  (e.g., freeHaskellFunPtr should be on
            that list)

  safe    = can call arbitrary foreign exported functions which, in turn
            might cause a garbage collection to happen (which is what you
            refer to later)

  threadsafe
          = safe but may invoke a blocking function so has to run on a
            separate thread.
            
I think GreenCard's %safecode generates safe ffi calls.  I'm not sure
if GreenCard can generate trheadsafe calls.

And I have no idea what threadsafe should mean for Hugs - I could
throw a call to yield into the translation and hope that is enough
(but, in general, it is not).

>> > And how would cross-ffi garbage-collection issues affect window >
>> parameters at startup?
>> 
>> Not sure what you mean - I can't think of any new issues in GC
>> which aren't present in Hugs.

> I was just trying to understand what safecode does, and the
> GreenCard docs say it's about foreign code that might trigger GCs.
> Which is allright, but at startup (when the window size parameters
> are ignored) there shouldn't be any GCs, so the question was how the
> lack of safecode is supposed to cause the effects I see.

Sorry.  That was me confusing safe with threadsafe.

> Thanks, that should help - I'll try it next week. I had all kinds of
> problems with the CVS makefile, not only that it doesn't like to be
> used in isolation, but complaints about missing files in the win32
> package itself, which seems rather unlikely (perhaps a side-effect
> of the cross-CVS dependencies?). 

That sounds like my experience of the hslibs tree - once it has been
assimilated it is really hard to use it in isolation.

The file Win32Dialogue.gc does genuinely seem to be missing something
- but it sounds like you had more problems than just that.

> Also, I'm quite confused about the current CVS structure - I'm
> looking in fptools/hslibs, but shouldn't all that have moved into
> the new libraries somewhere?

The new library structure is a work in progress - it'll move over eventually.  

This will gain momentum once Hugs switches over to using the new
hierarchial libraries.

And that will gain momentum once Hugs switches over to the new FFI.


-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/