Hi Alexander, aahringo@xxxxxxxxxx wrote on Tue, 30 Aug 2022 23:17:35 -0400: > 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. That's way more clever. I've changed that, no more pthread and no more race, thanks! Thanks, Miquèl
