I guess, I shouldn't have been surprised to be reading C code in this blog post, but man, even the 'clean' example has quite a bit of cruft, when looking at it from modern languages.
Like, this is the amount of ceremony I consider necessary (pseudo-code):
tracing::listen<ContextSwitch>(event -> {
//process ContextSwitch event here
})
It's pretty uncommon for low-level system APIs to use callbacks in that way. Think about it: every time the kernel wants to notify the user of an event, it would have to call a function in userspace... but there are a few problems with that. For starters: which thread is it calling from? The user process isn't going to have stack mappings and whatnot set up for an arbitrary kernel thread. And if we set that aside for the time being, in order to actually run the callback, you'd have to make a context switch from kernel to user mode as well, for each event.
The kind of API shown in the example is much more common: userspace allocatesa buffer, makes a syscall to request the kernel to copy queued events into the buffer until it fills up or no more events are pending, and then iterate over them again in userspace. A higher-level userspace library might hide this away behind a simplified interface with a callback function, but somewhere down the abstraction hierarchy it's almost certainly going to end up looking something like this.
Ah, good point. Yeah, in my mind, there was a thin wrapper library to allocate that buffer and such. Guess, we can't have that for the actual exposed interface.
I was also thinking, having to pass the size of the buffer and the buffer pointer separately, is just another C-ism, but that does make sense here then, too, because it's not implicitly relying on the memory layout of some List/Vec/whatever type.
Similarly, ETWGetEvents can only return a number of events, because it can't return a List/Vec/whatever.
Interesting perspective. And kind of weird to now be on-board with this API design, while also thinking I'm not touching that without a wrapper.
Maybe in a few decades, the Rust ABI will have stabilized and become ubiquitous enough, that we can have at least some of these amenities. But chances are, Rust will look quite antique by then, too, and we're back to writing wrappers anyways. 🙃
I guess, I shouldn't have been surprised to be reading C code in this blog post, but man, even the 'clean' example has quite a bit of cruft, when looking at it from modern languages.
Like, this is the amount of ceremony I consider necessary (pseudo-code):
tracing::listen<ContextSwitch>(event -> { //process ContextSwitch event here })It's pretty uncommon for low-level system APIs to use callbacks in that way. Think about it: every time the kernel wants to notify the user of an event, it would have to call a function in userspace... but there are a few problems with that. For starters: which thread is it calling from? The user process isn't going to have stack mappings and whatnot set up for an arbitrary kernel thread. And if we set that aside for the time being, in order to actually run the callback, you'd have to make a context switch from kernel to user mode as well, for each event.
The kind of API shown in the example is much more common: userspace allocatesa buffer, makes a syscall to request the kernel to copy queued events into the buffer until it fills up or no more events are pending, and then iterate over them again in userspace. A higher-level userspace library might hide this away behind a simplified interface with a callback function, but somewhere down the abstraction hierarchy it's almost certainly going to end up looking something like this.
Ah, good point. Yeah, in my mind, there was a thin wrapper library to allocate that buffer and such. Guess, we can't have that for the actual exposed interface.
I was also thinking, having to pass the size of the buffer and the buffer pointer separately, is just another C-ism, but that does make sense here then, too, because it's not implicitly relying on the memory layout of some List/Vec/whatever type.
Similarly,
ETWGetEventscan only return a number of events, because it can't return a List/Vec/whatever.Interesting perspective. And kind of weird to now be on-board with this API design, while also thinking I'm not touching that without a wrapper.
Maybe in a few decades, the Rust ABI will have stabilized and become ubiquitous enough, that we can have at least some of these amenities. But chances are, Rust will look quite antique by then, too, and we're back to writing wrappers anyways. 🙃