Rohan Verma

@asutosh97 TL;DR: ⚠️⚠️ ⚠️⚠️ **``ForkExec()`` will lead to a broken AOF, don't use it here! It defeats the purpose of introducing ``Fork()``** Here ``fork()`` is not used as in ``ForkExec()``...

I'll issue a fix for arm64 (m1 compatible) and the entire AOF stub will be upgraded to a stable implementation tomorrow.

@manosriram Ask arpit for review. He knows the requirements well.

@arpitbbhayani If you'll approve of the changes proposed, I would start preparing design documents for new data structure.

What about the storage engine? At the end of the day, you would still want it to run on a Linux/Windows Server and you had plans with jemalloc, I'm expecting...

Okay, so I'll hold my design for now. Btw a lot of changes are coming in windows version. I just implemented a entire POSIX system call for windows and it...

@arpitbbhayani Inspite of automatic GC here ```bash GODEBUG=gctrace=1 ./dice 2022/10/31 10:15:43 rolling the dice ⚄︎ 2022/10/31 10:15:43 starting an asynchronous TCP server on 0.0.0.0 7379 gc 1 @126.086s 0%: 0.044+0.33+0.026...

Along with IOCP addition, we have to introduce new system call invocations as defined in https://github.com/golang/go/blob/master/src/syscall/syscall_windows.go This should happen in a new file, let say - ``eval_windows_amd64.go``

Just got access to a windows server 2022, so I'll take this issue. Though I'm dealing with AOF currently, I'm willing to take this as well.

Turns out that IOCP behaves in contrast to Kqueue or Epoll. While Epoll waits for file descriptor to be available and then sends the message buffer, IO completion ports work...