<story><title>BSD socket API revamp</title><url>https://raw.githubusercontent.com/sustrik/dsock/master/rfc/sock-api-revamp-01.txt</url></story><parent_chain><item><author>cafxx</author><text>Am I missing something? It seems to propose to ditch all non-blocking APIs under the assumption that &amp;quot;runtimes&amp;quot; will provide lightweight concurrency. But AFAIK most (all?) runtimes that provide lightweight concurrency make extensive use of the non-blocking network APIs to work - including Golang, that is even cited as an example:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   During the decades since BSD sockets were first introduced the way
   they are used have changed significantly.  While in the beginning the
   user was supposed to fork a new process for each connection and do
   all the work using simple blocking calls nowadays they are expected
   to keep a pool of connections, check them via functions like poll()
   or kqueue() and dispatch any work to be done to one of the worker
   threads in a thread pool.  In other words, user is supposed to do
   both network and CPU scheduling. 
   [...]
   To address this problem, this memo assumes that there already exists
   an efficient concurrency implementation where forking a new
   lightweight process takes at most hundreds of nanoseconds and context
   switch takes tens of nanoseconds.  Note that there are already such
   concurrency systems deployed in the wild.  One well-known example are
   Golang&amp;#x27;s goroutines but there are others available as well.&lt;/code&gt;&lt;/pre&gt;</text></item></parent_chain><comment><author>JoshTriplett</author><text>Agreed; if anything, the &lt;i&gt;blocking&lt;/i&gt; API seems like the more artificial one, as the lowest-level implementation needs to handle the asynchronous receipt of data.  A network card receives data when it receives data, sends asynchronous notifications to the OS in the form of interrupts, and keeps receiving data while you pull data out of its buffers.  You can build a synchronous interface on top of that for convenience, but it fundamentally works asynchronously.</text></comment>
<story><title>BSD socket API revamp</title><url>https://raw.githubusercontent.com/sustrik/dsock/master/rfc/sock-api-revamp-01.txt</url></story><parent_chain><item><author>cafxx</author><text>Am I missing something? It seems to propose to ditch all non-blocking APIs under the assumption that &amp;quot;runtimes&amp;quot; will provide lightweight concurrency. But AFAIK most (all?) runtimes that provide lightweight concurrency make extensive use of the non-blocking network APIs to work - including Golang, that is even cited as an example:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   During the decades since BSD sockets were first introduced the way
   they are used have changed significantly.  While in the beginning the
   user was supposed to fork a new process for each connection and do
   all the work using simple blocking calls nowadays they are expected
   to keep a pool of connections, check them via functions like poll()
   or kqueue() and dispatch any work to be done to one of the worker
   threads in a thread pool.  In other words, user is supposed to do
   both network and CPU scheduling. 
   [...]
   To address this problem, this memo assumes that there already exists
   an efficient concurrency implementation where forking a new
   lightweight process takes at most hundreds of nanoseconds and context
   switch takes tens of nanoseconds.  Note that there are already such
   concurrency systems deployed in the wild.  One well-known example are
   Golang&amp;#x27;s goroutines but there are others available as well.&lt;/code&gt;&lt;/pre&gt;</text></item></parent_chain><comment><author>tptacek</author><text>Apart from the layering, which really has nothing to do with the sockets interface and can be (and has been, repeatedly, as this author knows) built today on top of the sockets interface, I don&amp;#x27;t really see what&amp;#x27;s interesting at all about this interface; it seems like a simple restatement of the existing blocking socket API.</text></comment>