On 09/04/2017 4:19 PM, Jonathan Marler wrote:
On Sunday, 9 April 2017 at 15:04:29 UTC, rikki cattermole wrote:
On 09/04/2017 3:56 PM, Jonathan Marler wrote:
On Sunday, 9 April 2017 at 14:49:14 UTC, rikki cattermole wrote:
Don't think too hard, times have changed since std.socket was written.
It certainly isn't designed for high performance hence e.g. libasync.
What an odd response... You don't think I should ask questions about why
decisions were made? If I took that approach how would I learn? And if
you discourage other people from asking questions by telling them they
are "thinking too hard" what kind of effect does that have on the
community?
As for "high performance", my questions have less to do with performance
than they do with an API that makes sense and doesn't feel "kludgy".
Oh sorry, I had a brain derp and thought at the end there you had that
you thought about it and it didn't make sense. Hence the slightly
weirder response.
Ah ok. That response was surprising to me coming from you (based on
what I've read from you in the past) but I see it was a misunderstanding.
What I meant is that, for common use cases it works well enough and it
does use reasonably sound API even if a bit cludgy.
When asking about classes, one of the big things is the vtable. They
are slow (compared to final classes and structs). This is the main
reason people want to switch over to structs instead of classes.
However if you take a look at the more performance aware libraries
like libasync you will see classes used extensively still.
Here is my suggestion, its a little harder to toy with ideas without
real code to show for it. All our more existing API's are mostly class
based for high performance sockets, timers ext. So, would you like to
have a go and explore this area since we are playing it a bit too safe
for your liking?
What I've found myself having to do is use the lower level platform
specific APIs that use socket_t and sockaddr, but then I get platform
dependencies and can't access alot of the library because it requires
the higher level Socket and Address objects. I would be willing to
explore this area, but before I do work in an area I research what's
already been done. Hence why I'm asking the questions about why it was
done this way in the first place. For all I know there are very good
reasons it was done this way that I just don't know about.
I personally disagree with the designs used in libasync[0] and
vibe-core(vibe.d's replacement/new core implementation). Very class
heavy and not enough emphasis on the event loop. But as you can see with
my lib SPEW[2] even I don't get away from classes (in fact I go all in).
Keep in mind only a handful of people really try to toy with this area.
So you may very well come up with a completely different strategy
that'll blow our minds without too much work. Existing implementations
all have there trade offs, you simply may choose a completely different
set and that is exciting.
[0] https://github.com/etcimon/libasync
[1] https://github.com/vibe-d/vibe-core
[2] https://github.com/Devisualization/spew
