Sha256: 837cc6b629d13cb9f3068b70a16ab914207657c89eff866fbc0d766d28e3cdc4

Contents?: true

Size: 1.44 KB

Versions: 4

Compression:

Stored size: 1.44 KB

Contents

#include <funchook.h>
#include <ruby.h>

static VALUE rb_sym_next;
static VALUE fiber_propagator;
static VALUE track_rb_fiber_new;
static VALUE track_rb_fiber_yield;

VALUE rb_fiber_new(VALUE (*func)(ANYARGS), VALUE obj);
VALUE (*rb_fiber_new_original)(VALUE (*func)(ANYARGS), VALUE obj);

VALUE rb_fiber_yield(int argc, const VALUE *argv);
VALUE (*rb_fiber_yield_original)(int argc, const VALUE *argv);

/* If you call `#next` on an enumerator object, that enumerator object
 * instantiates a fiber and runs its given proc inside of that fiber.
 * This minor design consideration presents a few significant edge-cases to us.
 * - match data from regex is bound to execution context, and it's an open
 *   question (but looking grim) as to whether we can propagate at that event.
 *   Ruby doesn't expose much around ECs, so both finding an event to hook
 *   and having a native way to access the EC data are onerous.
 * - fiber_yield is implemented with jmps in YARV, so our primary paradigm
 *   of operating on intercepted return values is off the table.
 *   (And heaven help you if you execute `#next` within an rb_protect call.)
 *   Luckily, we can read the fiber's return value before it executes a jump,
 *   so we have a point at which we can reliably propagate.
 */
VALUE rb_fiber_new_hook(VALUE (*func)(ANYARGS), VALUE obj);

VALUE rb_fiber_yield_hook(int argc, const VALUE *argv);

static int install_fiber_hooks();

void Init_cs__assess_fiber_track(void);

Version data entries

4 entries across 4 versions & 1 rubygems

Version Path
contrast-agent-3.12.2 ext/cs__assess_fiber_track/cs__assess_fiber_track.h
contrast-agent-3.12.1 ext/cs__assess_fiber_track/cs__assess_fiber_track.h
contrast-agent-3.12.0 ext/cs__assess_fiber_track/cs__assess_fiber_track.h
contrast-agent-3.11.0 ext/cs__assess_fiber_track/cs__assess_fiber_track.h