idb/FBControlCore/Utility/FBProcessIO.h

131 строка
3.3 KiB
C
Исходник Обычный вид История

/*
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*/
#import <Foundation/Foundation.h>
#import <FBControlCore/FBProcessStream.h>
NS_ASSUME_NONNULL_BEGIN
/**
A result of "attaching" to an IO object, realized as file descriptors.
*/
@interface FBProcessIOAttachment : NSObject
#pragma mark Properties
/**
The attachment for stdin.
*/
@property (nonatomic, strong, nullable, readonly) FBProcessStreamAttachment *stdIn;
/**
The attachment for stdout.
*/
@property (nonatomic, strong, nullable, readonly) FBProcessStreamAttachment *stdOut;
/**
The attachment for stderr.
*/
@property (nonatomic, strong, nullable, readonly) FBProcessStreamAttachment *stdErr;
/**
Detach from all the streams.
This may be called multiple times, the underlying streams will only detach once per instance.
*/
- (FBFuture<NSNull *> *)detach;
@end
/**
A result of "attaching" to an IO object, realized as file paths.
*/
@interface FBProcessFileAttachment : NSObject
/**
The attachment for stdout.
*/
@property (nonatomic, strong, nullable, readonly) id<FBProcessFileOutput> stdOut;
/**
The attachment for stderr.
*/
@property (nonatomic, strong, nullable, readonly) id<FBProcessFileOutput> stdErr;
/**
Detach from all the streams.
This may be called multiple times, the underlying streams will only detach once per instance.
*/
- (FBFuture<NSNull *> *)detach;
@end
/**
A composite of streams for the stdin, stdout and stderr streams connected to a process.
*/
@interface FBProcessIO <StdInType : id, StdOutType : id, StdErrType : id> : NSObject
#pragma mark Initializers
/**
The Designated Initializer.
@param stdIn the stdin.
@param stdOut the stdout.
@param stdErr the stderr.
@return a new FBProcessIO instance.
*/
- (instancetype)initWithStdIn:(nullable FBProcessInput<StdInType> *)stdIn stdOut:(nullable FBProcessOutput<StdOutType> *)stdOut stdErr:(nullable FBProcessOutput<StdErrType> *)stdErr;
/**
An IO object that accepts no input and returns no output.
*/
+ (instancetype)outputToDevNull;
#pragma mark Properties
/**
The FBProcessInput for stdin.
*/
@property (nonatomic, strong, nullable, readonly) FBProcessInput<StdInType> *stdIn;
/**
The FBProcessOutput for stdout.
*/
@property (nonatomic, strong, nullable, readonly) FBProcessOutput<StdOutType> *stdOut;
/**
The FBProcessOutput for stderr.
*/
@property (nonatomic, strong, nullable, readonly) FBProcessOutput<StdErrType> *stdErr;
/**
The queue to use.
*/
@property (nonatomic, strong, readonly) dispatch_queue_t queue;
#pragma mark Methods
/**
Attach to all the streams, returning the composite attachment for file descriptors.
Will error if any of the stream attachments error.
If any of the stream attachments error, then any succeeding attachments will detach.
FBProcessIO: Attachment only once, detachment allowed multiple times Summary: `-[FBProcessIO detach]` should be called at least one time once a process has exited. However, the current implementation for pipe-based consumers (data consumers, block consumers etc) if `-[FBProcessIO detach]` will error out and bail early another detachment is occurring. That started detachment may finish after the error condition, if the caller is listening for the errored-out attachment, then detachment errors can occur before the detachment has finished elsewhere This identifies another race condition; D29194120 (https://github.com/facebook/idb/commit/dac5809e4198cc576568a2c6fd0ed94f2732fbd8) fixes problems in `FBTask` where the properties on it do not wait until IO is drained. However, there's still a problem that relates to `-[FBProcessIO detach]`. 1) A process is running, with the process futures all wrapped with detachment handling. 2) The `-[FBProcessIO detach]` is in sequence for `statLoc`, `exitCode` and `signal`. This causes each output to teardown. 3) The same detachment code is called for each of stdIn, stdErr, stdOut. 4) The teardown for `statLoc`'s `stdOut` teardown can succeed first 5) The teardown for `exitCode`'s `stdOut` teardown then fails and the error is handled 6) However, the real teardown in #4 is still pending. This means that `exitCode` can have resolved, before the teardown has actually occurred, which we explicitly wanted to avoid There was a further problem with the `FBProcessIO` class. Since the internal queue used for serialisation was a concurrent queue, all of the serialisation that was necessary to prevent attachments and detachments from fighting with each other was effectively redundant. This could have resulted in crashes and other indeterminate states if attachments and detachments ran concurrently with themselves or each other. Reviewed By: jbardini Differential Revision: D29195990 fbshipit-source-id: 50722ce1eb4293ac6cf6183459d169b42e0c40e7
2021-06-17 18:13:15 +03:00
This should only be called once. Calling attach more than once per instance will fail.
*/
- (FBFuture<FBProcessIOAttachment *> *)attach;
/**
Attach to all the streams, returning the composite attachment for file paths.
Will error if any of the stream attachments error.
If any of the stream attachments error, then any succeeding attachments will detach.
*/
- (FBFuture<FBProcessFileAttachment *> *)attachViaFile;
@end
NS_ASSUME_NONNULL_END