The major perk is that you queue computation (read: "thread"), not callbacks, so you can write stuff like this:
while true:
let bytesRead = read(fd, buf, bufsize)
if bytesRead == -1:
if errno == EAGAIN or errno == EWOULDBLOCK:
wait(fd, Read) # Queue this computation until the fd is readable
else:
raise newIOError(errno)
else:
return bytesRead
Even IOCP is made simple here:
let overlapped = new Overlapped
# <do your operation>
if error == WSA_IO_PENDING:
wait(handle, overlapped) # Queue this computation until the overlapped operation is complete
if WSAGetOverlappedResult(...) == FALSE:
raise newIOError(errno)
else: ...
I think this kind of simplicity afforded to user code is rarely seen in most languages, which is why I decided to base my stdlib on this.
Yes, we use valgrind for the compiler and stdlib test suite. The testament tool supports this, however it's not in widespread use outside of the compiler and stdlib, so documentation is rather sparse.
Since Nim uses the C compiler to generate executables, you should be able to use `--passC:-fsanitize=memory --passL:-fsanitize=memory` to enable msan. For maximum effectiveness the flags `-d:useMalloc --gc:orc` should also be used.
`-d:useMalloc` tells Nim to allocate memory using libc's malloc instead of our TSLF implementation. This should provide adequate compatibility for use with external inspection tools. We do
`--gc:orc` because this is one of the only GCs that support -d:useMalloc (the other being arc).
I believe the phrasing might not be clear to everyone, so here's a reduced version:
* Nim's current async implementation creates a lot of cycles in the graph, so ARC can't collect them.
* ORC is then developed as ARC + cycle collector to solve this issue, and it has been a success.
* This 1.4 release introduces ORC to everyone so that we can have mass testing for this new GC and eventually move torwards ORC as the default GC.
TL;DR: ORC works with everything† and will be the new default GC in the future. Your old Nim code will continue to work, and will just get faster‡.
† We are not sure that it's bug-free yet, which is why it's not the default for this release.
‡ Most of the time ORC speeds things up, but there are edge cases where it might slow things down. You're encouraged to test your code with --gc:orc against our default GC and report performance regressions.
The major perk is that you queue computation (read: "thread"), not callbacks, so you can write stuff like this:
Even IOCP is made simple here:
I think this kind of simplicity afforded to user code is rarely seen in most languages, which is why I decided to base my stdlib on this.