Hi Hubert, Sorry for the delay in getting back to you. That sounds like a bug - we could use a shared lock if we have no other way, but it sounds like signal_from_channel maybe holding onto its lock longer than it needs to. For example if that function sends an event to the UI thread, but is holding the lock while waiting for the event to complete, this would prevent the UI thread from getting through paintEvent and processing the evening.
With regard to oscilloscope modes. Yes this would be very welcome. However, looping sample_thread_proc probably isn't the right way to do it. libsigrok does have support for actual oscilloscopes. It signals the start/end of a new sweep by SR_DF_FRAME_BEGIN/END. At the moment PV doesn't handle these - but it could and should. Now for devices that don't support continuous-sweeping, we can emulate that in software. Now the question is where should this functionality go? Should it be in PulseView? I think not, because this is functionality other clients can use. Should it go in the drivers? In many cases yes, I would say, but would the sweep emulation have to be duplicated across many drivers? Would it go in libsigrok's core somehow? I don't know. It would be good to have a discussion with use_ and biot on the #sigrok IRC channel. The other issue is that painting needs work to improve speed. It would be good to bring back some OpenGL painting. But also the various painting/data storage algorithms need to be revisited. Joel On 05/08/15 10:35, Hubert Chaumette wrote: > Hi, > > I am experimenting on a continuous oscilloscope-like mode for > PulseView (I basically added a loop in sample_thread_proc), and I > encounter a deadlock on pv::Session::signals_mutex_. > It appears both pv::view::Viewport::paintEvent (main UI thread) and > pv::Session::signal_from_channel (sampling thread) try to acquire the > mutex exclusively. > > The deadlock disappears when replacing lock_guard by shared_lock in > signal_from_channel. So, is exclusive access to pv::Session::signals_ > necessary there? > > Best regards, > > Hubert Chaumette > > ------------------------------------------------------------------------------ > _______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > > ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
