e-gy / yasync Goto Github PK

Currently all smart pointers are created using a constructor. if new succeeds, but pointer construction fails, (an excepetion is thrown, ) and new isn't deleted.

Converty all of them to make_shared.

This issue is nothing compared to #2.

Currently everything is hanging on noexcept assumption. That is, library internals shouldn't throw, library uses shouldn't throw - as long as that is the case, everyone is happy.

If however for whatever reason something somewhere throws an exception, at best a portion of internals is violently murdered. But more likely that not the entire engine, and everything running on it too of course, enters unpredictable state.
Of course most thread implemetations say that whenever a thread is errored and not caught, the program is terminated. So the unpredictable state above becomes program termination. Ain't sure which one's better.

By ensuring strong noexcept on at least all of async internals, and drivers, we can guarantee that:

• the internals are fail-safe, to the extent of stability of the entire program
• throwing in user code will terminate the program

Of course we can learn to handle async exceptions akin Node otherwise, right?

Generators should be capable to indicate doneness with no further results.
Indicating that the result is last and no further requests should be made is cool and all. But for example implementing a filtering generator requires it to fetch 1 element ahead and at least 1 element from the underlying source to have validated the precondition.

The bugger is that current system provides strong guarantees for await chaining processing of a single element a breeze.

Outside futures with uncompleted status somehow leak through into threado (where they get force casted into generated futures). which obviously sends everything into segv.

What's more curious is that this behaviour is only observed on Linux (and conveniently doesn't always reproduce).

It seems it has to do with listening socket's future used for acception conns..?

Linux has a new """polling""" interface - LibAIO/io_submit.
Built on proactive model, much more similar to IOCPL from Win32 land, and reducing the number of syscalls required, it should be considered to be used instead of epoll.

Currently (in straightforward) use cases, when shutdown sequence is initiated IO completion operations are closed and IO Yengine is nuked. Without regards to any pending operations... that will go on to linger and block wle. See E-gy/sbewe-redips#1.

To properly close IO operations, a dedicated tracking component similar to notificers should be introduced into IO Yengine, and a wioe (for blocking the nuking).

Arguably, new IO operations should still be accepted during shutdown sequence, in order to allow other potential IO operations to complete (ex. proxying). In other words, wioe is to function pretty much exactly akin to its wle brotherin - as an indicator of end of external triggers on entry, and indicator of end of processing capabilites on exit.

Therefor (along other reasons such as indirect IO dependence), IO Yengine can not rely on underlying IO notifications mechanism for usage tracking.