Joseph Devietti
Joseph Devietti
@AlanMorel I have been trying to port an existing Next 13 app, so I ended up assembling [a little example repo](https://github.com/devietti/trpc-next13-app). Only the client makes RPC calls, though, no RPCs...
I looked over the code and nothing stands out as clearly wrong. It seems like the libc interface is the same as the syscall interface (timer_t* passed in 3rd argument)....
Ah, very interesting @wangbj!
I don't know that this test would expose nondeterminism in the `timer_id`. It seems like the id might just be an address in some table (maybe in the kernel?). Maybe...
yeah, those seem like heap addresses so maybe that's where libc puts this table.
With 20fae14 I handled this the same way as `getrlimit`: always return infinity (commit 90a0eb0). We can do something more refined later if need be.
Didn't mean to close this via github magic commit parsing! I believe the root cause of this behavior is that syscall argument 4 lives in `r10`, not `rcx`. `rcx` happened...
Well, I have lots of opinions on this one. 3¢ worth or even more! I vote in favor of rust. I have created a similar test suite for another project...
As another data point, in the `logilab-common` package, the`pytest` program does a read from `/proc/53/stat` (using its own pid to navigate `/proc`, not sure why it doesn't just use `/proc/self`...
@gatoWololo makes an excellent point that, while the tracer (which runs inside the container) needs access to the real `/proc`, we could mount it out-of-the-way at `/dtproc`, and verify that...