[BUG] C Macro not populating value! about cython HOT 7 CLOSED

There's a lot here that we can't see easily. However: what you're relying on is that Cython doesn't use temporary variables for any of the arguments to the macro.

So you're saying

__io_uring_for_each_cqe(&ring.ptr, head, cqe.ptr)

Must not be translated to

tmp1 = &ring.ptr;
tmp2 = head;
tmp3 = cqe.ptr;
__io_uring_for_each_cqe(tmp1, tmp2, tmp3);

This isn't something we necessarily promise not to do.

from cython.

I'd suggest writing a small inline C function that calls the macro with a signature of

void inline_function(
        __io_uring** ring,
        unsigned int* head,
        __io_uring_cqe** cqe)

instead

from cython.

I am not sure what Cython does internally. All I want is to see results like:

print(cqe.res) # should return `0`
print(cqe.user_data) # should return either `1` or `2`

Which doesn't seem to be happening! As you can see head returns 2 so we can tell that function/wrapper itself is working to some extent.

This is now the io_uring_for_each_cqe function is used in C side https://github.com/axboe/liburing/blob/master/examples/proxy.c#L1949-L1954

from cython.

The problematic part is the assignment to head and cqe inside of the macro:

head = *(ring)->cq.khead;					\
cqe = (head != io_uring_smp_load_acquire((ring)->cq.ktail) ? \

Here, the macro is assuming that the assignment has an effect in the outside world, which may not be the case, depending on what head and cqe are. If they are stored in temporary variables, then there will not be a re-assignment back to where their values were originally taken from. It's the kind of macro that should generally be avoided because it has several side-effects and makes implicit assumptions that may or may not apply.

As @da-woods suggested, wrap it in an actual function instead.

from cython.

Ended up writing bellow code and its working!!! Thank you so much @da-woods, glad its finally working. I been at it for couple of days now. Though its really frustrating not being able to solves these problems within Cython itself and having to do these monkey patch with C code seem abnormal!

It would be nice if you guys enabled Discussions option on GitHub so people can talk about Cython.

'''
    static inline void inline_function(struct io_uring* ring,
                                       unsigned int head,
                                       struct io_uring_cqe* cqe)
    {
        io_uring_for_each_cqe(ring, head, cqe);
    }
'''

void inline_function(__io_uring* ring, unsigned int head, __io_uring_cqe* cqe)


cpdef unsigned int io_uring_for_each_cqe(io_uring ring, io_uring_cqe cqe):
    cdef unsigned int   head=0
    inline_function(&ring.ptr, head, cqe.ptr)
    return head

from cython.

Thanks @scoder for your explanation, it makes sense. As far as C programmer is concerned it works and they are happy with it, when you try to wrap it in ffi you run into all kinds of issues... I still have few other normal function that glitch out, I haven't narrowed down the bug yet! It works sometimes and other time it does not, mixing it with async coroutine and python reference, bug has many places to hide :-)

from cython.

@scoder p.s. cqe reference to memory is actually managed be the C library ring itself, that's probably why the author is ok with reassigned cqe = (head ... as they do.

from cython.