I'm implementing the latest hs_init()/hs_exit() interface in GHC, and came across an ambiguity or omission in the spec. We're clear that this sequence should be allowed: hs_init(..) hs_init(..) hs_exit() hs_exit() but what about hs_init(..) hs_exit() hs_init(..) hs_exit() That is, should the Haskell system be able to start itself up again after shutting down? It looks like this is desirable from a modularity viewpoint: eg. a C program initialises library A which uses Haskell internally, then de-initialises library A, then initialises library B which also uses Haskell internally. Unfortunately, this is going to require quite a bit of extra work in GHC to get right, and it looks like I'm going to have to examine a lot of code to make sure it is "double-init-safe". Thoughts? Cheers, Simon
On 28-Jan-2003, Simon Marlow <simonmar@microsoft.com> wrote:
I'm implementing the latest hs_init()/hs_exit() interface in GHC, and came across an ambiguity or omission in the spec. We're clear that this sequence should be allowed:
hs_init(..) hs_init(..) hs_exit() hs_exit()
but what about
hs_init(..) hs_exit() hs_init(..) hs_exit()
That is, should the Haskell system be able to start itself up again after shutting down? It looks like this is desirable from a modularity viewpoint: eg. a C program initialises library A which uses Haskell internally, then de-initialises library A, then initialises library B which also uses Haskell internally.
Unfortunately, this is going to require quite a bit of extra work in GHC to get right, and it looks like I'm going to have to examine a lot of code to make sure it is "double-init-safe". Thoughts?
FWIW, getting this sort of thing to work properly with the Mercury implementation would also be quite a lot of work. Still, I do think that this sort of thing should be supported. Sometimes standards should serve to advance the state of the art, rather than merely standardizing on the flaws of existing implementations, and I think this is one of those time.s -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson <fjh@cs.mu.OZ.AU> wrote,
On 28-Jan-2003, Simon Marlow <simonmar@microsoft.com> wrote:
I'm implementing the latest hs_init()/hs_exit() interface in GHC, and came across an ambiguity or omission in the spec. We're clear that this sequence should be allowed:
hs_init(..) hs_init(..) hs_exit() hs_exit()
but what about
hs_init(..) hs_exit() hs_init(..) hs_exit()
That is, should the Haskell system be able to start itself up again after shutting down? It looks like this is desirable from a modularity viewpoint: eg. a C program initialises library A which uses Haskell internally, then de-initialises library A, then initialises library B which also uses Haskell internally.
Unfortunately, this is going to require quite a bit of extra work in GHC to get right, and it looks like I'm going to have to examine a lot of code to make sure it is "double-init-safe". Thoughts?
FWIW, getting this sort of thing to work properly with the Mercury implementation would also be quite a lot of work.
Still, I do think that this sort of thing should be supported. Sometimes standards should serve to advance the state of the art, rather than merely standardizing on the flaws of existing implementations, and I think this is one of those time.s
Ok. I will add to the spec that complete de-initialisation followed (re)initialisation should be supported. Cheers, Manuel
I personally would like to see both work. I have done some work with dynamically loaded modules implemented in haskell and being able to do the iterated initializations seems important. there was talk that this would be difficult given the current state of GHC's RTS, I am not sure what the conclusion was. my vote was to put it in the spec that it should work and have GHC document that it is nonconforming in that manner until its implementation catches up. John On Tue, Jan 28, 2003 at 03:54:10PM -0000, Simon Marlow wrote:
I'm implementing the latest hs_init()/hs_exit() interface in GHC, and came across an ambiguity or omission in the spec. We're clear that this sequence should be allowed:
hs_init(..) hs_init(..) hs_exit() hs_exit()
but what about
hs_init(..) hs_exit() hs_init(..) hs_exit()
That is, should the Haskell system be able to start itself up again after shutting down? It looks like this is desirable from a modularity viewpoint: eg. a C program initialises library A which uses Haskell internally, then de-initialises library A, then initialises library B which also uses Haskell internally.
Unfortunately, this is going to require quite a bit of extra work in GHC to get right, and it looks like I'm going to have to examine a lot of code to make sure it is "double-init-safe". Thoughts?
Cheers, Simon
_______________________________________________ FFI mailing list FFI@haskell.org http://www.haskell.org/mailman/listinfo/ffi
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
Just out of curiosity, what would happen if hs_exit were a noop? if it left haskell initialized? I imagine there would be a space leak if you expected the rts's heap storage to be reclaimed, but is there any user-observable state which would cause programs to behave oddly? Just curious mainly, I don't advocate this as a solution. John On Tue, Jan 28, 2003 at 03:54:10PM -0000, Simon Marlow wrote:
but what about
hs_init(..) hs_exit() hs_init(..) hs_exit()
That is, should the Haskell system be able to start itself up again after shutting down? It looks like this is desirable from a modularity viewpoint: eg. a C program initialises library A which uses Haskell internally, then de-initialises library A, then initialises library B which also uses Haskell internally.
Unfortunately, this is going to require quite a bit of extra work in GHC to get right, and it looks like I'm going to have to examine a lot of code to make sure it is "double-init-safe". Thoughts?
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
participants (4)
-
Fergus Henderson -
John Meacham -
Manuel M T Chakravarty -
Simon Marlow