Hi, On Mon, Aug 29, 2022 at 8:57 AM Alexander Aring <aahringo@xxxxxxxxxx> wrote: > > Hi, > > On Mon, Aug 29, 2022 at 4:37 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > > Hi Alexander, > > > > aahringo@xxxxxxxxxx wrote on Sun, 28 Aug 2022 09:55:24 -0400: > > > > > Hi, > > > > > > On Fri, Aug 26, 2022 at 6:50 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > ... > > > > > > > > I've updated the tools so that we have: > > > > > > > > * "scan trigger" which does not block > > > > * "scan monitor" which displays with a pretty output the new > > > > coordinators and stops blocking when the scan is over (either because > > > > it reached the last channel to scan, or it got aborted) > > > > * "scan abort" which stops an ongoing scan > > > > * "scan" which is the same as "scan trigger; scan monitor", and will > > > > > > no, there is a race in the design of "scan trigger; scan monitor". > > > > Right, I've used pthread to first start the monitoring, before actually > > triggering the scan. That should be enough. > > > > I think we should look at this, because it requires that all > applications link to pthreads if we offer such an API. Any thoughts > about alternative ways, can it not be done over libnl, that libnl > internally used e.g. select()? The above example is only regarding the > process context. > I think pthreads are not necessary here. If we don't close and open the nl socket everything should be queued. Forget that with select(), just send() and recv() (whatever that is underneath of libnl) should be enough. - Alex
