External polling (not wakeup) or deferred execution

[ldct-polemos]

I think the library is great in terms of offered features, but at the same time it is difficult to build abstractions on top of it. Let's take a look at two scenarios:

• application with an already established event loop framework (custom or popular like libuv) where all services reside in the main thread and use worker threads for long processing operations, while inter-service communication happens on the main thread, without the need to any locking mechanism;
• applications with multiple threads, where each service of the application resides (for simplicity) in a separate thread. Each service exposes methods to asynchronously get/put member variables or to invoke method and asynchronously publish the results in the caller thread. Again without locks.

Common to both scenarios is that each service must be reachable via an http endpoint (same address and port).

Non trivial applications fall in one of the two cases above. How can you integrate mongoose in such two scenarios? Wakeup() is just a way to exit the event loop to do something else, like spinning another event loop. But what if another library has the same way of handling interruptions? That is not scalable.

Popular library approaches: consider uwebsocket library: the defer() method allows to execute a lambda in the http server thread. Other libs define an interface to allow file descriptors to be polled from outside. It's a pity that this awesome library does not have any of these two. Such features would make this lib the most complete, extensible and portable I've seen till now in the area of http.

[scaprile]

I beg to differ. The vast majority of our customers are embedded systems and microcontrollers with no OS. Mongoose was never designed aiming to where you want to use it. Mongoose does not depend on other libraries, it must run in baremetal scenarios.
mg_wakeup() is not "a way to exit the event loop to do something else", it is a way to wake up the manager thread when other thread has data for it to deliver right now. Data is sent when the event manager runs; instead of waiting for external data or a timeout, you tell it to run now and hence deliver your data; thing that won't happen if using our lock-free queue.

[ldct-polemos]

Enabling an external loop is just a matter of registering a few callbacks (add_fd, remove_fd..) and maybe a macro to turn the feature on/off to add zero overhead if not used.
That would not break baremetal compatibility.

Wakeup() is good for freetos-like OS but that is suboptimal for any POSIX compliant platforms which mongoose do support. (I even saw a macro enabling epoll() for Linux). That's my point: support is there for advance concepts like poll/select/epoll but then the lib forces the user to spawn a dedicated thread (consuming memory and forcing context switches) to make things works. File descriptors could be polled/selected/epolled by a thread that runs mongoose and other N things. And everything would stay In a single thread; writing code would be faster and resource usage lower and bare metal people still happy.

Anyways.

[scaprile]

@cpq WDYT ?