February 24, 2022

On Thursday, 24 February 2022 at 09:11:01 UTC, eugene wrote:

>

In my case (I was working with REDIS KVS at the moment)
exact scenario was as follows:

  • prog gets EPOLLOUT (write() won't block)
  • prog writes()'s data to REDIS ("successfully")
  • prog gets EPOLLERR|EPOLLHUP

After this I see that I need to reconnect, but I've already send
some data which had gone to nowhere.

People sometimes recommend using usual non-blocking sockets,
but it is not the case.

errhh... usual blocking sockets, of course.
however then I have to deal with multiprocess/multithread
architechture, but my goal was fine-graned concurrency
within single process.

February 24, 2022

On Thursday, 24 February 2022 at 11:27:56 UTC, Tejas wrote:

> >

Wagner F. et al
Modeling Software with Finite State Machines: A Practical Approach

I've adopted some ideas from this book to POSIX/Linux API.
see also http://www.stateworks.com/
Thank you so much!

Also there is very nice discussion

I'll just cite:

"
Pure event-driven programming (without blocking) naturally partitions the code into small chunks that handle events. State machines partition the code even finer, because you have small chunks that are called only for a specific state-event combination.
"

This is exactly about what I've mentioned:
event-driven + state-machines = fine-graned-concurrency

1 2 3
Next ›   Last »