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 <ikj12...@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())
>
>
