4 ms·

Any reading you'd recommend regarding your second point? I've never heard that about C++ before.

stefs 11y ago
i think this is strange. i'm not a c++ programmer, but the evented frameworks (node.js or vert.x) are doing it the other way round: use threads only for IO (or computation so heavy it's practically blocking). the complete opposite.
- misframer 11y ago
  libuv (used by Node.js) uses epoll, kqueue, etc. for network I/O. It uses a thread pool for all file operations.
  - stefs 11y ago
    ah, well - when reading "blocking io" i first thought about the file system. so does my point still stand? using a threadpool for disk IO does go against "threads should only be used to exercise multiple CPU cores and never as a way to work around blocking IO." or am i still not getting this?
- jcoffland 11y ago
  Actually node.js does it the same way. Under the covers node.js handles IO with libev which is an event library.
  - misframer 11y ago
    They use libuv now.
deleted 11y ago
[deleted]
jcoffland 11y ago
There are really two parts to point 2. 2.a. is about performance. And while not specifically about C++ this article covers the main idea http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html 2.b. is about avoiding deadlocks and race conditions. Threaded programming in C++ is dangerous. For years I would have said, that I could avoid deadlocks and race conditions by virtue of being a good programmer. However, I've debugged enough of my own code to know this is not always true. If you only use threads for data driven computation, then you greatly reduce the risks. On the other hand if you have multiple threads running around accessing anything and everything in your program then you need a lot of thread locks which is tedious to implement and not well supported in C++ (vs. say the synchronized keyword in Java), does not perform well and still it is very easy to make mistakes. The point is that there is no reason to let threads run willy nilly because you can do event driven programming in C++ (libev, libevent, libuv) and most programs (or rather most parts of a program) are not computationally intensive. edit: Here's a great resource on the topic of threading. From the SQlite FAQ "Threads are evil. Avoid them." http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....
- deleted 11y ago
  [deleted]
brobinson 11y ago
This paper by the guy who runs Mailinator is really interesting: https://www.mailinator.com/tymaPaulMultithreaded.pdf https://www.mailinator.com/tymaPaulMultithreaded.pdf It's about Java, not C++, but it's still relevant.

stefs 11y ago

i think this is strange. i'm not a c++ programmer, but the evented frameworks (node.js or vert.x) are doing it the other way round: use threads only for IO (or computation so heavy it's practically blocking). the complete opposite.

misframer 11y ago
libuv (used by Node.js) uses epoll, kqueue, etc. for network I/O. It uses a thread pool for all file operations.
- stefs 11y ago
  ah, well - when reading "blocking io" i first thought about the file system. so does my point still stand? using a threadpool for disk IO does go against "threads should only be used to exercise multiple CPU cores and never as a way to work around blocking IO." or am i still not getting this?
jcoffland 11y ago
Actually node.js does it the same way. Under the covers node.js handles IO with libev which is an event library.
- misframer 11y ago
  They use libuv now.

deleted 11y ago

[deleted]

jcoffland 11y ago

There are really two parts to point 2. 2.a. is about performance. And while not specifically about C++ this article covers the main idea http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html 2.b. is about avoiding deadlocks and race conditions. Threaded programming in C++ is dangerous. For years I would have said, that I could avoid deadlocks and race conditions by virtue of being a good programmer. However, I've debugged enough of my own code to know this is not always true. If you only use threads for data driven computation, then you greatly reduce the risks. On the other hand if you have multiple threads running around accessing anything and everything in your program then you need a lot of thread locks which is tedious to implement and not well supported in C++ (vs. say the synchronized keyword in Java), does not perform well and still it is very easy to make mistakes. The point is that there is no reason to let threads run willy nilly because you can do event driven programming in C++ (libev, libevent, libuv) and most programs (or rather most parts of a program) are not computationally intensive. edit: Here's a great resource on the topic of threading. From the SQlite FAQ "Threads are evil. Avoid them." http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....

deleted 11y ago
[deleted]

brobinson 11y ago

This paper by the guy who runs Mailinator is really interesting: https://www.mailinator.com/tymaPaulMultithreaded.pdf https://www.mailinator.com/tymaPaulMultithreaded.pdf It's about Java, not C++, but it's still relevant.