[DRAFT] ProcessID, Signal, SignalSet, TaskInfo, ResourceUsageInfo #20

milseman · 2021-02-05T17:30:16Z

Just a draft of low-level strongly typed wrappers for getting the current PID, querying usage information of a processes, and wrappers for signals and signal sets.

lorentey · 2021-02-24T22:13:05Z

Sources/System/Process/ProcessID.swift

+
+// FIXME(DO NOT MERGE): We need to find a way around this. We want to declare
+// a typealias to a struct from a header, but don't want downstream to import
+// Darwin or the whole header just for that.


It turns out we should just import Darwin! Since System isn't an overlay, it doesn't need to reexport the module, and merely importing it won't pollute the client namespace with C junk. 🎉

Can we use Darwin's types though? Also, can we do this with our CSystem module as well (which is needed for Linux, since libC isn't libSystem).

I think so -- if people only import System, they will still be able to refer to these types by one of their System typealiases (such as the ones in CInterop or RawValue). (They can't spell Darwin.foo unless they import it.)

CSystem is trickier, because it shouldn't be a public module, so we should continue to import it @_implementationOnly.

Sources/System/Process/Signal.swift

lorentey · 2021-02-25T00:00:43Z

Sources/System/Process/Signal.swift

+ public static var busError: Signal { Signal(SIGBUS) }
+
+ /// SIGSEGV (11): segmentation violation (default behavior: create core image)
+ public static var segfault: Signal { Signal(SIGSEGV) }


Segfault is a colloquialism; segmentationFault or segmentationViolation seems like a better fit.

Suggested change

public static var segfault: Signal { Signal(SIGSEGV) }

public static var segmentationViolation: Signal { Signal(SIGSEGV) }

not super how I feel about this. We're not using segmentation anymore but paging, so spelling "segfault" out may not make it easier to find?

Having an unavailable-renamed entry for SIGSEGV would hopefully help point to whatever name we choose.

That's true. But segmentationViolation is still not what this will be sent for so I'd be inclined to leave the as a "term of art".

Yeah, this is sort of like hangup in that the name has somehow outlived its original meaning, which is now a complete anachronism. SIGSEGV is defined as "segmentation violation" in the man pages, so at least this expansion isn't likely to confuse anyone.

@weissi, what would you propose as a replacement? Note that System is supposed to follow the Swift naming conventions, so the original arbitrary abbreviations need to be replaced, no matter how well known.

FWIW, POSIX describes SIGSEGV as "Invalid memory reference". Would we be willing to name it invalidMemoryReference?

SEGV is such an (in)famous signal, it may be worth spending a term-of-art card on segmentationViolation, no matter how far it is from the current meaning...

invalidMemoryReference is IMHO much better than segmentationViolation. Both names however aren't as good as SIGSEGV or sigsegv IMHO. If you want to program your operating system directly, I think any translation of names is counterproductive and will lead to avoidable bugs, imprecise reviews, etc.

Sources/System/Process/Signal.swift

lorentey · 2021-02-25T00:59:13Z

Sources/System/Process/ProcessID.swift

+extension CInterop {
+ public typealias PID = Int32
+ public typealias ProcTaskInfo = proc_taskinfo // FIXME
+ public typealias RUsageInfo = rusage_info_current // FIXME


We have the option to just go with the original type names here, but I think it's still nice to have these typealiases.

lorentey · 2021-02-25T01:04:24Z

Sources/System/Process/ResourceUsageInfo.swift

+// FIXME: names
+extension ProcessID.ResourceUsageInfo {
+ // FIXME: UUID proper type
+ public typealias UUID = (


Foundation already has a wrapper for uuid_t -- perhaps we should investigate shrinking it into System.

lorentey · 2021-02-25T01:09:10Z

Sources/System/Process/ResourceUsageInfo.swift

+ public var uuid: UUID { rawValue.ri_uuid }
+
+ /// `ri_user_time`: TBD
+ public var userTime: UInt64 { rawValue.ri_user_time }


We should specify units for all these dimensioned quantities, ideally at the type system level. Should these time intervals return whatever we end up using for timespec_t?

Unfortunately the headers are not clear what even is here. It's like that ResourceUsageInfo will be split off from this PR eventually.

lorentey · 2021-02-25T01:13:30Z

Sources/System/Process/SignalSet.swift

+}
+
+
+public struct SignalSet: Hashable, Codable {


I wonder if Codable conformance is a good idea here -- sigset_t values aren't necessarily portable between platforms/architectures.

They are definitely not. Neither are signal numbers, errno codes, or so.

That's true, they would have to be encoded/decoded as the string of function calls.

I don't suppose there is a portable/easy way to list the full contents of a signal set, is there? (If we had one, we could maybe add Collection and/or SetAlgebra conformance. OTOH, that'd probably be gilding the lily...)

lorentey · 2021-02-25T01:17:04Z

Sources/System/Process/SignalSet.swift

+ 1 == withUnsafePointer { sigismember($0, sig.rawValue) }
+ }
+
+ public static var empty: SignalSet {


We should also provide a no-argument initializer that creates the empty set.

weissi

random drive by

weissi · 2021-02-25T15:45:43Z

Sources/System/Process/Signal.swift

+ public static var badSyscall: Signal { Signal(SIGSYS) }
+
+ /// SIGPIPE (13): write on a pipe with no reader (default behavior: terminate process)
+ public static var pipe: Signal { Signal(SIGPIPE) }


hmm, you can also get them on sockets...

weissi · 2021-02-25T15:46:19Z

Sources/System/Process/Signal.swift

+ public static var stop: Signal { Signal(SIGSTOP) }
+
+ /// SIGTSTP (18): stop signal generated from keyboard (default behavior: stop process)
+ public static var temporaryStop: Signal { Signal(SIGTSTP) }


I think SIGSTOP is uncatchable so it's not a request.

Co-authored-by: Karoy Lorentey <[email protected]>

karwa · 2021-05-13T22:33:09Z

Sources/System/Process/ProcessID.swift

+ public typealias RUsageInfo = rusage_info_current // FIXME
+}
+
+public struct ProcessID: RawRepresentable, Hashable, Codable {


It seems to me that this is more of a Process (i.e. a system object identified by a pid) than a ProcessID - related APIs such as resource usage are really properties of the process more than the ID.

This struct is the handle to the process, it's very much like a file descriptor. It's not "safe" to assume it's still valid after a process is torn down, etc.

I've been thinking that a Process type would probably be more like an actor with interfaces for interprocess communication. Similarly with a proper File type (though that might be a moveonly buffered struct). ProcessID here is the lower-level systems model of that where we can communicate using descriptors or other forms of IPC.

Do you think Process will be part of SystemPackage or layered on top? If it is part of SystemPackage is there a way to make a stub Process type so that this type could be Process.ID? I'm not sure if this will work for ABI stability (though I also can't say that it won't), but maybe we can create an enum Process that we then upgrade to an actor (or whatever).

milseman · 2021-10-03T14:49:38Z

I think shipping this requires that we finish fleshing out posix_spawn functionality, otherwise we wouldn't have a good vetting of some of the design here.

sindresorhus · 2022-05-31T19:27:27Z

Sources/System/Process/TaskInfo.swift

+ }
+ }
+ return TaskInfo(result)
+ }


I don't know what the intended scope is for this pull request, but a common need is to get the path and name for a PID. proc_pidpath and proc_name.

milseman added 3 commits February 5, 2021 08:44

WIP: PID, and resource / task info

ad80d0f

Signal and SignalSet

0ebaa29

TaskInfo and ResourceUsageInfo struct queries

544fc8a

milseman mentioned this pull request Feb 15, 2021

API Roadmap #16

Open

lorentey reviewed Feb 25, 2021

View reviewed changes

weissi reviewed Feb 25, 2021

View reviewed changes

milseman and others added 9 commits February 25, 2021 09:02

Update Sources/System/Process/Signal.swift

881a8ad

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

0c32e4e

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

c96a3e6

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

a051d71

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

153e5d3

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

e8b5ab4

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

9edaf16

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

5bc82a4

Co-authored-by: Karoy Lorentey <[email protected]>

Update Sources/System/Process/Signal.swift

9830717

Co-authored-by: Karoy Lorentey <[email protected]>

karwa reviewed May 13, 2021

View reviewed changes

GeorgeLyon mentioned this pull request Nov 13, 2021

POSIX Spawn APIs #70

Open

sindresorhus reviewed May 31, 2022

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DRAFT] ProcessID, Signal, SignalSet, TaskInfo, ResourceUsageInfo #20

[DRAFT] ProcessID, Signal, SignalSet, TaskInfo, ResourceUsageInfo #20

milseman commented Feb 5, 2021

lorentey Feb 24, 2021

milseman Feb 25, 2021

lorentey Feb 26, 2021

lorentey Feb 25, 2021

weissi Feb 25, 2021

milseman Feb 25, 2021

weissi Feb 25, 2021

lorentey Feb 26, 2021 •

edited

lorentey Feb 26, 2021

weissi Feb 26, 2021

lorentey Feb 25, 2021

lorentey Feb 25, 2021

lorentey Feb 25, 2021

milseman Feb 25, 2021

lorentey Feb 25, 2021

weissi Feb 25, 2021

milseman Feb 25, 2021

lorentey Feb 26, 2021

lorentey Feb 25, 2021

weissi left a comment

weissi Feb 25, 2021

weissi Feb 25, 2021

karwa May 13, 2021

milseman Oct 3, 2021

GeorgeLyon Nov 13, 2021

milseman commented Oct 3, 2021

sindresorhus May 31, 2022

	public static var segfault: Signal { Signal(SIGSEGV) }
	public static var segmentationViolation: Signal { Signal(SIGSEGV) }

[DRAFT] ProcessID, Signal, SignalSet, TaskInfo, ResourceUsageInfo #20

Are you sure you want to change the base?

[DRAFT] ProcessID, Signal, SignalSet, TaskInfo, ResourceUsageInfo #20

Conversation

milseman commented Feb 5, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lorentey Feb 26, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weissi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

milseman commented Oct 3, 2021

Choose a reason for hiding this comment

lorentey Feb 26, 2021 •

edited