Как расширение Ruby C может хранить процесс для последующего выполнения? - PullRequest
Новая
       34

Как расширение Ruby C может хранить процесс для последующего выполнения?

0 голосов
/ 27 сентября 2018

Цель: разрешить расширению c получать блок / proc для отложенного выполнения при сохранении текущего контекста выполнения.

У меня есть метод в c (доступный для ruby), который принимает callback (через VALUE hashаргумент) или block. 

// For brevity, lets assume m_CBYO is setup to make a CBYO module available to ruby
extern VALUE m_CBYO;
VALUE CBYO_add_callback(VALUE callback)
{
    if (rb_block_given_p()) {
        callback = rb_block_proc();
    }

    if (NIL_P(callback)) {
        rb_raise(rb_eArgError, "either a block or callback proc is required");
    }

    // method is called here to add the callback proc to rb_callbacks
}
rb_define_module_function(m_CBYO, "add_callback", CBYO_add_callback, 1);

У меня есть структура, которую я использую для хранения этих дополнительных данных: 

struct rb_callback
{
    VALUE rb_cb;
    unsigned long long lastcall;
    struct rb_callback *next;
};
static struct rb_callback *rb_callbacks = NULL;

Когда придет время (вызваноepoll), я перебираю обратные вызовы и выполняю каждый обратный вызов: 

rb_funcall(cb->rb_cb, rb_intern("call"), 0);

Когда это происходит, я вижу, что он успешно выполняет код ruby ​​в обратном вызове, однако он экранирует текущий контекст выполнения.

Пример: 

# From ruby including the above extension
CBYO.add_callback do
    puts "Hey now."
end

loop do
    puts "Waiting for signal..."
    sleep 1
end

Когда сигнал получен (через epoll), я увижу следующее: 

$> Waiting for signal...
$> Waiting for signal...
$> Hey now.
$> // process hangs
$> // Another signal occurs
$> [BUG] vm_call_cfunc - cfp consistency error

Иногда я могу получить более одного сигнала наобработать до того, как ошибка снова появится.

1 Ответ

0 голосов
/ 07 декабря 2018

Я нашел ответ при исследовании аналогичной проблемы .

Как оказалось, я тоже пытался использовать нативные сигналы потоков (с pthread_create), которые не поддерживаются сМРТ.

TLDR;В настоящее время Ruby VM не является (на момент написания) потокобезопасным.Посмотрите эту хорошую статью о Ruby Threading для лучшего общего понимания того, как работать в этих границах.

Вы можете использовать Ruby's native_thread_create (rb_thread_t * th) который будет использовать pthread_create за сценой.Есть некоторые недостатки, о которых вы можете прочитать в документации выше определения метода.Затем вы можете запустить обратный вызов с помощью метода Ruby rb_thread_call_with_gvl .Кроме того, я не делал этого здесь, но было бы неплохо создать метод-обертку, чтобы вы могли использовать rb_protect для обработки исключений, которые может вызвать обратный вызов (в противном случае они будут проглочены виртуальной машиной). 

VALUE execute_callback(VALUE callback)
{
    return rb_funcall(callback, rb_intern("call"), 0);
}

// execute the callback when the thread receives signal
rb_thread_call_with_gvl(execute_callback, data->callback);
...