Re: Regression in GR3.10

[Josh Morman]

I think the way to properly handle GIL from long running calls is to add  py::call_guard<py::gil_scoped_release>() to the definition of the method binding

.def("delete_head", &msg_queue::delete_head, D(msg_queue, delete_head))

I haven't tried this here, but I've used it on similar python bindings

https://pybind11.readthedocs.io/en/stable/advanced/misc.html?highlight=call_guard#global-interpreter-lock-gil

Josh

On Wed, Jun 15, 2022 at 3:28 PM ikjtel <ikj1234i@yahoo.com> wrote:

Josh

Many thanks for your reply.   I needed some direction - this is
exactly what I was looking for.

> msgq API probably should be deprecated, but it is in fact there in 3.10.

Yeah, I remember reading a pronouncement many moons ago from M. Braun
about nuking msgq.  Always dreaded this day - OP25 is a heavy user of it.
Ref: https://osmocom.org/projects/op25

A few quick stats: OP25 has 160 lines in 25 files (.cc and .h) matching
'msg_q' or 'msgq'; 7 calls to insert_tail() from 5 files (.cc and .h);
34 calls to insert_tail() or delete_head() from 5 files (.py).

> Are you able to use delete_head_nowait instead?

delete_head_nowait never used to work for me, but seems to have
improved in gr3.10.  The script pasted below should (and does
in gr3.10) print no output but in gr3.8 you get a seg fault.

A preliminary diagnosis (speaking imprecisely - it was long ago)
suggested delete_head_nowait in gr3.8 was returning some kind of
"fancy_pointer(nil)" rather than simply "nil" which would have
been properly rendered back to python as "None" (and gr3.10 looks
like it gets this right).

Short term I think we could visit the approx. 10 sites in python code
and change delete_head over to _nowait.  Since the returned value can't
be trusted (gr3.8 and below in the no-message case) we'll need to skip
if empty_p() is true.

One problem with the _nowait is what to do with all the processor
time we suddenly have on our hands.  If we sleep for some arbitrary
period it adds latency in the app that wasn't there before.

Longer term is the question of what to do about msgq in OP25.  The
idea of getting rid of all the code that relies on it is agonizing.
It may make more sense to fork the msgq code out of gnuradio-runtime.
We could probably find some hack that would take care of the GIL problem
in a proper way...    Comments certainly welcome.

Max

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/usr/bin/env python           # seg faults in gr 3.8

import sys

from gnuradio import gr

my_msgq = gr.msg_queue(1)

p = my_msgq.delete_head_nowait()
if p:
    sys.stderr.write('found msg\n')
    sys.stderr.flush()
    print('type is %s' % p.type())