GitLab

Duncan Coutts pushed to branch wip/io-manager-deadlock-detection at Glasgow Haskell Compiler / GHC

Commits:

53eead15

by Wolfgang Jeltsch at 2026-09-24T20:12:03-04:00

Correct the documentation of `explicitUnits`

Resolves #27787.

35bf6f4b

by Simon Jakobi at 2026-09-24T20:12:49-04:00

Remove stale specHeader bullet from Note [Don't make fillers for constraint types]

The Note said that Specialise.specHeader also calls mkAbsentFiller.
abfc224a27c removed that call: the specialiser no longer drops dead
arguments at all, see Note [Do not drop dead args from specialisations]
in GHC.Core.Opt.Specialise.

Assisted-by: Claude Fable 5.1

1abef1ef
by Wolfgang Jeltsch at 2026-09-25T17:02:07-04:00
```
Improve the `mhu-closure` makefile
```
a79a68ea
by Wolfgang Jeltsch at 2026-09-25T17:02:07-04:00
```
Make `ghci-multi` hide all unneeded packages
```

d6e72450

by Wolfgang Jeltsch at 2026-09-25T17:02:07-04:00

Improve the definition of the home unit closure property

c9a2766d

by Wolfgang Jeltsch at 2026-09-25T17:02:07-04:00

Re-implement the home unit closure check

Compared to the previous implementation, the new one has the following
advantages:

  * It is correct.
      - It distinguishes between units that have the same unit ID but
        different ABI hashes.
      - When `-hide-all-packages` is not used, it considers as home unit
        dependencies also units that are made implicitly available
        because they are in the package database.
  * It seems to be faster in usual settings.
      - In particular, it does not have a preparation phase in which it
        merges the dependency information from all home units, so that
        its running time does not grow linearly with the size of the
        package database in normal Cabal scenarios.
  * It is (hopefully) clearer.
  * It is better documented.

fa96acf8

by Wolfgang Jeltsch at 2026-09-25T17:02:07-04:00

Remove erroneous GHC flag in `hadrian-multi`

The flag was `-Werror=-Wno-error=incomplete-record-selectors`. Its
purpose was to permit incomplete record selectors, but because of the
illegal combination of `-Werror=` and `-Wno-error` it was ignored,
without any negative consequences.

9f48a5b9

by Alan Zimmerman at 2026-09-25T17:02:50-04:00

EPA: Add specific layout field to AnnList

Up to now AnnList has effectively served to represent lists of things
having layout, regardless of whether they do or not.

In Haskell, layout is optional in many places, as there is also an
alternative syntax using braces and semi-colons, which is free-form.

This commit introduces AnnListLayout, a data structure capturing this
distinction.

It is deliberately set up similarly to EpLayout, so that these two can
be merged in time.

The transition is done mechanically, where AnnListBraces is not used
yet, the original Nothing case maps to AnnListNoLayout, and the Just
case to AnnListLayout.

Later commits will fine tune these against the actual parser layout.

388f9c66

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Move idle GC tracking to its own file, step 1 of 2

Add a new IdleGC.{c,h} module. Move the RecentActivity type,
recent_activity variable and {get,set}RecentActivity wrappers.

fac92964

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Move idle GC functionality to its own file, step 2 of 2

We can now fully encapsulate the recent_activity state, exposing just
three hooks, and one query used in the scheduler and timer tick.

This is a prelude to making changes to the implementation of tracking
when to perform an idle gc.

39167176

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Correct comments in idle GC code

The comments still referred to stopTimer/startTimer. These were
replaced recently by pauseTimer/unpauseTimer, but the comment was not
updated.

6ceae159

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Make signal handling be a responsibility of the I/O manager(s)

Previously it was scattered between I/O managers and the scheduler, and
especially the scheduler's deadlock detection.

Previously the scheduler would poll for pending signals each iteration
of the scheduler loop. The scheduler also had some hairy signal
functionality in the deadlock detection: in the non-threaded RTS (only)
if there were still no threads running after deadlock detection then it
would block waiting for signals.

But signals can and (in my opinion) should be thought of as just a funny
kind of I/O, and thus should be a responsibility of the I/O manager.

So now we have the I/O managers poll for signals when they are polling
for I/O completion (and removing the separate poll in the scheduler).
And when I/O managers block waiting for I/O then they now also start
signal handlers if they get interrupted by a signal. Crucially, if there
is no pending I/O or timers, the awaitCompletedTimeoutsOrIO will still
block waiting for signals.

This patch puts us into an intermediate state: it temporarily breaks
deadlock detection in the non-threaded RTS. The waiting on I/O currently
happens before deadlock detection. This means we'll now wait forever on
signals before doing deadlock detection. We need to move waiting after
deadlock detection. We'll do that in a later patch.

2d010a57

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Clean up the RTS internal signal handling API

Now that the I/O manager is responsible for signals, we can simplify the
API we present for signal handling.

We now just need startPendingSignalHandlers, which is called from the
I/O managers. We can get rid of awaitUserSignals. We also don't need
RtsSignals.h to re-export the platform-specific posix/Signals.h or
win32/ConsoleHandler.h

We can also hide more of the implementation of signals. Less has to be
exposed in posix/Signals.h or win32/ConsoleHandler.h. Indeed,
posix/Signals.h becomes empty and we remove it. Partly this is because
we don't need inline functions (or macros) in the interface.

Also remove signal_handlers from RTS ABI exported symbols list. It does
not appear to have any users in the core libs, and its really an
internal implementation detail. It should not be exposed unless it's
really necessary.

345837c6

by Duncan Coutts at 2026-09-27T18:43:02+01:00

In the scheduler, move I/O blocking after deadlock detection

To make deadlock detection effective in the non-threaded RTS when there
are deadlocked threads and other unrelated threads waiting on I/O, we
need to arrange to do deadlock detection before we block in scheduler
to wait on I/O.

The solution is to:

1. adjust scheduleFindWork, which runs before deadlock detection, to
   only poll for I/O and not block; and
2. add a step after deadlock detection to wait on I/O if there are
   still no threads to run (and there's any I/O or timeouts outstanding)

The scheduleCheckBlockedThreads is now so simple that it made more sense
to inline it into scheduleFindWork.

2456bc80

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Remove bogus anyPendingTimeoutsOrIO guard from scheduleDetectDeadlock

The deadlock detection was only invoked if both of these conditions
hold:
1. the run queue is empty
2. there is no pending I/O or timeouts

The second condition is unnecessary. The deadlock detection mechanism
can find deadlocks even if there are other threads waiting on I/O or
timers. Having this extra condition means that we fail to detect
blocked threads if there are any threads waiting on I/O or timers.

Part of fixing issue #26408

84a9ada4

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Don't consider pending I/O for early context switch optimisation

Context switches are normally initiated by the timer signal. If however
the user specifies "context switch as often as possible", with +RTS -C0
then the scheduler arranges for an early context switch (when it's just
about to run a Haskell thread).

Context switching very often is expensive, so as an optimisation there
cases where we do not arrange an early context switch:
1. if there's no other threads to run
2. if there is no pending I/O or timers

This patch eliminates case 2, leaving only case 1.

The rationale is as follows. The use of this was inconsistent across
platforms and threaded/non-threaded RTS ways. It only worked on the
non-threaded RTS and on Windows only worked for the win32-legacy I/O
manager. On all other combinations anyPendingTimeoutsOrIO would always
return false. The fact that nobody noticed and complained about this
inconsistency suggests that the feature is not relied upon.

If however it turns out that applications do rely on this, then the
proper thing to do is not to restore this check, but to add a new I/O
manager hint function that returns if there is any pending events that
are likely to happen *soon*: for example timeouts expiring within one
timeslice, or I/O waits on things likely to complete soon like disk I/O,
but not for example socket/pipe I/O.

The motivation to avoid this use of anyPendingTimeoutsOrIO is to
allow us to eliminate anyPendingTimeoutsOrIO entirely. All other uses
of this are just guards on {await,poll}CompletedTimeoutsOrIO and
the guards can safely be folded into those functions. This will better
cope with some I/O managers having no proper implementation of
anyPendingTimeoutsOrIO.

Ultimately this will let us simplify the scheduler which currently has
to have special #ifdef mingw32_HOST_OS cases to cope with the lack of a
working anyPendingTimeoutsOrIO for some Windows I/O managers

0bfa75e3

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Remove anyPendingTimeoutsOrIO guarding {poll,await}CompletedTimeoutsOrIO

Previously the API of the I/O manager used a two step process: check
anyPendingTimeoutsOrIO and then call {poll,await}CompletedTimeoutsOrIO.
This was primarily there as a performance thing, to cheaply check if we
need to do anything.

And then because anyPendingTimeoutsOrIO existed, it was used for other
things too. We have now eliminated the other uses, and are just left
with the performance pattern.

But this was problematic because not all I/O managers correctly
implement anyPendingTimeoutsOrIO (specifically the win32 ones), and now
that we also make I/O managers responsible for signals then we need to
poll/await even if there is no pending I/O or timeouts. If there is no
pending I/O or timeouts then await needs to degenerate to just waiting
forever for any signals.

1af20d4f

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Remove anyPendingTimeoutsOrIO, it is no longer used

And this avoids the problems arising from the win32 I/O managers having
had a bogus implementation.

b89c0adc

by Duncan Coutts at 2026-09-27T18:43:02+01:00

Remove second scheduler call to awaitCompletedTimeoutsOrIO

Previously awaitCompletedTimeoutsOrIO was called both before and after
deadlock detection in the scheduler. The reason for that was that the
win32 I/O managers had a bogus implementation of anyPendingTimeoutsOrIO
and this was used to guard the call of awaitCompletedTimeoutsOrIO prior
to deadlock detection. This meant the first call site was never actually
called when using the win32 I/O managers. This was the reason for the
second call: the first one was never used. What a mess.

So now we have a simple design in the scheduler:
1. poll for completed I/O, timers or signals
2. if no runnable threads: do deadlock detection
3. if still no runnable threads: block waiting for I/O, timers or
   signals.

e9d80b12