Attention is currently required from: fixeria.

pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-trx/+/43112?usp=email )

Change subject: libosmo-trx/ep: flush pending TRXC messages on endpoint teardown ......................................................................

Patch Set 2:

(2 comments)

File libosmo-trx/src/trx_ep.c:

https://gerrit.osmocom.org/c/osmo-trx/+/43112/comment/a1437bbd_df468fb3?usp=... : PS2, Line 245: if (res > 0 && osmo_iofd_txqueue_len(iofd) > 0) in io_uring backend, with asynchronous write operations, the fact that the userspace iofd txqueue is empty doesn't necessarily mean that the write operation has finished.

freeing the iofd at that point could probably turn into the write being cancelled, etc.

As mentioned imho you need to track count of wrote (completed) bytes vs enqueued bytes, in order to figure out whether the stream is really done.

https://gerrit.osmocom.org/c/osmo-trx/+/43112/comment/8a909ae3_9405e418?usp=... : PS2, Line 269: talloc_steal(OTC_GLOBAL, iofd); IMHO this is not a good idea, since you are keeping a socket alive without the data domain of the program knowing about it, hidding it to the user. For instance, my program does osmo_trx_ep_close() and then since according to the API it's closed, I do a open(), which will potentially fail because the ocal bound addr+port is still in use by the older socket.

You should incorporate the logic of "closing" being a known state into the public API, so the user of the ep can figure out when it can eg. re-open it or free it. This can be seen in the osmo-pcap wrf structure I mentioned.