[catnap] Implementing Missing System Calls

[ppenna]

Description

In this PR I fix the following issues:

• [catnap] wait_any() Is Not Implemented #64
• [catnap] push2() Is Not Implemented #67

[BrianZill]

What is this doing? If the idea is to remove the key from the SchedulerHandle, "handle.take_key()" would be clearer. The comment doesn't really explain what is happening either.

[ppenna]

Sure, I'll change it to handle.take_key(), but the bad semantics that you have noticed should be fixed in the scheduler, when a better reference counting mechanism is implemented and the scheduling system is re-architected. For now, I have just decoupled it and made it more to work on abstract futures.

Overall, the use of the SchedulerHandle is overload and it is used to refer to both, short-living and long-living operations. In the latter case the reference count in the underlying WakerPageRef is bumped, and in the former case the reference count is not.

To summary up, this line is doing what the comment says: putting back the underlying operation in the scheduling queue (instead of dropping it). What is going on is the following:

• When we call get_handle() the scheduler performs a lookup in its internal tables and gets a unique identifier for the given operation. When it does so, we create a SchedulerHandle from a given WakerPageRef, but we don't bump the associated reference count.
• When the SchedulerHandle is dropped, it would call the custom Drop trait implementation. This would decrement the reference counting of the underlying WakerPageRef, if key is not a None value.
• If the target ScheduleHandle is a short-living one, the drop will happen afterwards, when the associated future completes. Thus, to avoid a double-free scenario, we take out the underlying key in the ScheduleHandle, leaving a None on its place and preventing drop() to run.

This solution is ugly, the exposed interface is not clear and I'm not happy with it.

For now, I've created issue https://github.com/demikernel/catwalk/issues/2 to keep track of this.

Let me know if you have any suggestions on the comment to make the whole mess clearer.

[BrianZill]

Okay, I see. Yes, that is ugly. I would change the comment to say "Return this operation to the scheduling queue by removing the associated key (which would otherwise cause the operation to be freed)" or something like that.

I would also change the code to be just "handle.take_key();". There's no need to "into_raw()" or "unwrap()" because you're not doing anything with the result.

[ppenna]

Sure.

[BrianZill]

Thanks for making those changes.