Anyway. I have an idea for eliminating the read copy in the async IO code. Something I've done in other C programs is this:
- Track the pending events which the store client code schedules callbacks into itself (ie, the eventAdd() for later processing, and pending disk IO)
- Split storeClientUnregister() into two parts - one which sets a "shutting down" flag, and another which does the hard work
- assert() that API methods aren't called (ie, storeClientRef(), etc) if the shutting down flag is set - ie, they shouldn't be at the present time, so any instance of that happening means that some callback is occuring where it shouldn't be and getting further than it should be!
- On event/disk callback completion, clear the relevant flags and see if the store client is completely ready to be destroyed. Only then destroy it.
I'm just worried that there's going to be weirdness in how the store client code is being called. Grr.
Anyway. If this is successful and proves itself in production, I'll then change the disk APIs to also enforce that the callback data remains valid for the lifetime of the scheduled IO. Which IMHO it should be. As I said earlier, using tricks like reference counted buffers shouldn't be a crutch for a bad API design..
Post a Comment