Hi Keith,
in principle, you could continue using the multi_usrp in **one** of the
processes. The real problem stems from the question of who inherits the sockets
(in the case of network USRPs), the USB handles, or kernel ring buffer handles.
In the end, only one process might react to packets coming from the USRP. Also,
this is C++, so if you don't watch out in your main process, and your
multi_usrp loses scope, its destructor would be called, with devastating
effects on the state of your USRP.
On the other hand, there is, at least as far as I can remember from the top of
my head, nothing to react to until you start a streamer. But I wouldn't
recommend relying on that as kind of API; I don't think we guarantee usability
of a multi_usrp after forking, but the last word on that is Martin's.
Maybe if you described your use case, we could chime in with approaches.
Best regards,
Marcus
On 14 May 2018 18:09:51 GMT+02:00, Keith k via USRP-users
<usrp-users@lists.ettus.com> wrote:
>Hello all
>
>My intuition tells me this would be a bad idea, but before I try
>anything
>with this, does anyone have any thoughts about how the multi-usrp
>object
>would react in a situation where the process has been forked? I know
>that
>the call to create a multi-usrp object will fail if called in a second
>process, so I imagine it won't like being in 2 separate address spaces.
>
>--
>-Keith Kotyk
--
This was written on my cellular phone. whilst an impressive piece of
engineering, this might not be the perfect device to write emails on - please
excuse my brevity.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
