Skip to content

Logging fails when using ThreadJobs #8

@Jaykul

Description

@Jaykul

The commands all use a static HostIOInterceptor.Instance

When AttachToHost is called on that static instance (from any command) the current InternalHost shim (the one that's active in the current runspace) gets attached. It's only detached when the module is unloaded -- so there can only ever be one logged runspace per process.

In a parallel runspace scenario (like ThreadJob or PoshRSJob) each runspace has it's own InternalHost` shim (even though none of them have an actual host).

With many InternalHosts, and only one Interceptor, only the first one to Attach actually gets logged, and the rest silently fail to log with no errors! The Attach simply returns and only the first runspace in a process logs properly -- unless the module is unloaded from that runspace before the registration of listeners in the second runspace.

To fix this we'd have to cache the attached hosts somehow (probably by creating a HostIOInterceptor per host).

We could try using a caching Factory pattern to have a static HostIOInterceptor HostIOInterceptor.GetInterceptor(PSHost Host) which would keep a collection of active interceptors and return the right one for the given host.

So for instance, Enable-LogFile could call:

HostIOInterceptor.GetInstance(Host).AddSubscriber();

Instead of:

HostIOInterceptor.Instance.AttachToHost(Host);
HostIOInterceptor.Instance.AddSubscriber(logFile);

I believe this would require a change to the LogFile as well (in order to be able to pause logging when it's writing exceptions). It would need to either store a reference to the HostIOInterceptor which it was created for, or a pointer to the Paused property, or a callback/event for pausing and unpausing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions