Opened 9 years ago

Last modified 12 days ago

#3372 new feature request

Allow for multiple linker instances

Reported by: jcpetruzza Owned by:
Priority: low Milestone:
Component: Runtime System (Linker) Version:
Keywords: Cc: howard_b_golden@…, ezyang@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: #3658 Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously.

Attachments (1)

Main.hs (2.4 KB) - added by jcpetruzza 9 years ago.
Example that fails due to this limitation

Download all attachments as: .zip

Change History (21)

Changed 9 years ago by jcpetruzza

Attachment: Main.hs added

Example that fails due to this limitation

comment:1 Changed 9 years ago by igloo

difficulty: Unknown
Milestone: 6.14.1

comment:2 Changed 8 years ago by igloo

Milestone: 7.0.17.0.2

comment:3 Changed 8 years ago by igloo

Milestone: 7.0.27.2.1

comment:4 Changed 7 years ago by hgolden

Cc: howard_b_golden@… added
Type of failure: None/Unknown

I looked at the attachment. Is it a significant problem to use separate processes when two interpreters are needed? Could you give a use case for this feature that shows its usefulness? Thanks.

comment:5 in reply to:  4 Changed 7 years ago by jcpetruzza

Replying to hgolden:

[...] Could you give a use case for this feature that shows its usefulness? Thanks.

You may want to use ghc in interactive mode to implement some sort of evaluator as part of a Haskell IDE (e.g., like this). You will then want to have one evaluator per opened project and each evaluator naturally corresponds to a ghc session. One can implement this with multiple processes but in an arguably less convenient way.

comment:6 Changed 7 years ago by simonmar

This is indeed a significant ugliness. I think fixing it would be fairly mechanical, just package up the linker's state as an object that gets passed in to every call, and then in GHC the PersistentLinkerState becomes the holder for the RTS linker state and is carried around in the HscEnv rather than being a global variable.

comment:7 Changed 7 years ago by igloo

Milestone: 7.2.17.4.1

comment:8 Changed 7 years ago by igloo

Milestone: 7.4.17.6.1
Priority: normallow

comment:9 Changed 6 years ago by igloo

Milestone: 7.6.17.6.2

comment:10 Changed 6 years ago by igloo

Blocked By: 3658 added

comment:11 Changed 6 years ago by ezyang

Cc: ezyang@… added

comment:12 Changed 4 years ago by thomie

Corresponding wiki page: MultipleLinkerInstances

comment:13 Changed 4 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:14 Changed 4 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:15 Changed 3 years ago by ezyang

Component: CompilerRuntime System (Linker)

comment:16 Changed 3 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:17 Changed 3 years ago by thomie

Milestone: 8.0.1

comment:18 Changed 2 weeks ago by gelisam

I believe this has been fixed in ghc 7.10.1, can we close this?

At least, the release notes for ghc 7.10.1 claim that the linker API is now thread-safe: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-10-1.html#idp5860656

See https://github.com/mvdan/hint/issues/68#issuecomment-419088813 for the rest of my archeological search on the history of this ticket and why I believe this is now fixed.

comment:19 Changed 2 weeks ago by simonmar

This is not fixed. The C API for the linker in the runtime was made thread-safe, so that multiple C clients could call it simultaneously, but GHC still has a single global instance of its own linker state.

comment:20 Changed 12 days ago by JulianLeviston

I created the afore-linked issue in hint. I wanted to record my use-case here, too, which is that I'm building a meta-editing system (ie it can edit portions of its own code) and my codebase needs 3 to 4 levels of interpreting to have typechecked interpreted hotswappable zero downtime code modification.

Note: See TracTickets for help on using tickets.