Timeline for C++ Syncronous Poll Wrapper v2
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 15, 2016 at 10:51 | vote | accept | cloakedlearning | ||
| Jul 19, 2016 at 15:39 | comment | added | cloakedlearning | right - I guess I didn't put enough thought into that. | |
| Jul 19, 2016 at 14:01 | comment | added | bobah |
thread_local exposed via API is a very bad idea for many reasons (for example because someone may cache it and C++ syntax won't stop it from happening).
|
|
| Jul 19, 2016 at 13:06 | comment | added | cloakedlearning |
Yeah, I see your point. My current use case isn't for extremely high throughput sockets, so I'm thinking about making the vector thread_local for now as a compromise (to avoid most of the allocations).
|
|
| Jul 19, 2016 at 12:26 | comment | added | bobah | Usually you'd want the code running in the IO loop to be as lightweight as possible as it potentially gets executed tens of millions times per second. any copying, no matter how little may slow it down noticeably. best is to write a micro benchmark on a loopback socket and see for yourself. | |
| Jul 19, 2016 at 12:03 | comment | added | cloakedlearning | Yeah, that makes sense. Perhaps I could use a stack allocator to avoid changing my design? The vector is almost always going to contain a pointer of some variety so most likely a max of 16bytes per element. | |
| Jul 19, 2016 at 11:29 | history | answered | bobah | CC BY-SA 3.0 |