自REDHAWK 2.1.0以来发布组件的问题

时间:2017-05-10 17:47:55

标签: redhawksdr

我在CentOS 7上使用REDHAWK 2.1.0,并使用ossie.utils.sb在Python Sandbox中运行组件。

有时当我调用“component.releaseObject()”时,它就会挂起。实际上从不调用releaseObject的C ++实现。以前的REDHAWK版本没有遇到这种情况。

设置是连接到某个组件的rh.SigGen。只有当Siggen上的“sri_blocking”设置为True,并且连接的组件在serviceFunction()中花费更多时间时,似乎才会出现此问题。

当rh.FileReader是源代码时,我没有遇到同样的问题。我很好奇,如果这与FileReader在组件停止时结束流有关。 SigGen不会结束当前流。

我创建了一个test_component,其中包含一个属性“delay”。它的serviceFunction()看起来像:

bulkio::InFloatPort::dataTransfer *pkt = dataFloat_in->getPacket(bulkio::Const::NON_BLOCKING);

if (not pkt) {
    return NOOP;
}

if (pkt->sriChanged) {
    dataFloat_out->pushSRI(pkt->SRI);
}

if (pkt->inputQueueFlushed) {
    LOG_WARN(test_component_i, "INPUT QUEUE FLUSHED!");
}

usleep(delay);

dataFloat_out->pushPacket(&pkt->dataBuffer[0], pkt->dataBuffer.size(), pkt->T, pkt->EOS, pkt->streamID);

delete pkt;
return NORMAL;

延迟用于模拟处理的时间长度。在我的情况下,当使用SigGen作为源时,100 usec延迟导致下面脚本的干净退出。但是,1000 usec导致第一个“releaseObject()”调用挂起:

#!/usr/bin/python

from ossie.utils import sb
import numpy as np


def setupSigGen():
    c = sb.launch('rh.SigGen')
    c.sri_blocking = True
    c.throttle = False
    c.xfer_len = 10000
    return c, 'dataFloat_out'


def setupFileReader():
    np.array(range(10000), dtype=np.float).tofile('/tmp/fileReaderInput.32f')
    c = sb.launch('rh.FileReader')
    c.advanced_properties.throttle_rate = '-1'
    c.advanced_properties.ignore_header_metadata = True
    c.advanced_properties.looping = True
    c.sample_rate = '1Gsps'
    c.file_format = 'FLOAT'
    c.source_uri = 'file:///tmp/fileReaderInput.32f'
    return c, 'dataFloat_out'


def startSigGen(c):
    c.start()


def startFileReader(c):
    c.start()
    c.playback_state = 'PLAY'


def setupComp(config=None):
    c = sb.launch('test_component')
    if config is not None:
        c.configure(config)
    return c, 'dataFloat_in'


if __name__ == '__main__':
    import argparse

    parser = argparse.ArgumentParser()

    parser.add_argument(
        '-f',
        '--use-file-reader',
        default = False,
        action = 'store_true')

    parser.add_argument(
        '-d',
        '--delay',
        type = int,
        default = 1000)

    args = parser.parse_args()

    if args.use_file_reader == True:
        setupSource = setupFileReader
        startSource = startFileReader
        print 'Using rh.FileReader'
    else:
        setupSource = setupSigGen
        startSource = startSigGen
        print 'Using rh.SigGen'
    src, usesPortName = setupSource()
    comp, providesPortName = setupComp({'delay': args.delay})
    src.connect(comp,
                usesPortName=usesPortName,
                providesPortName=providesPortName)
    comp.start()
    startSource(src)
    raw_input('Enter any key to stop...')
    src.stop()
    comp.stop()
    src.releaseObject() # <--- hangs here when src is an rh.SigGen
    comp.releaseObject()

如果我删除了“stop()”调用,而只是使用“releaseObject()”,那么脚本也会完全退出。

就实现源组件而言,这是否意味着源组件应该在“stop()”上发送流结束? (“stop()”总是表示STOP,还是PAUSE?)rh.FileReader使用“playback_state”属性来提供PAUSING。这是一个很好的做法吗?

我还尝试使用自定义文件源组件作为源代码。除非我在“stop()”上发送流末尾,否则会出现同样的问题。

1 个答案:

答案 0 :(得分:0)

显示的场景肯定会锁定。问题是当沙箱在发布之前清理组件时,test_component的输入队列已满(并且没有被服务)。作为清理的一部分,沙箱会断开组件。作为断开连接的一部分,端口基类发送一个零长度数据包,EOS设置为true表示流已完成;这个电话是锁定的。推动组件和沙箱的组件都不会超时,从而导致锁定状态。这只是一个沙箱问题,不应该是正在运行的域的问题。

在REDHAWK 2.1.0中,我建议在停止数据源组件后设置睡眠。这应该清空队列(你只需要一个空插槽),并且可以为与断开连接相关的调用提供服务。

此问题已在REDHAWK 2.1.1(https://github.com/redhawksdr/redhawk/releases/tag/2.1.1

中修复