Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #67263 > unrolled thread

Why can't I understand what coroutines are?

Back to article view | Back to comp.lang.c++

Contents

  Why can't I understand what coroutines are? Juha Nieminen <nospam@thanks.invalid> - 2019-08-04 09:37 +0000
    Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-04 02:58 -0700
      Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-04 09:18 -0400
        Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-04 11:15 -0700
    Re: Why can't I understand what coroutines are? Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2019-08-04 04:58 -0600
      Re: Why can't I understand what coroutines are? Juha Nieminen <nospam@thanks.invalid> - 2019-08-05 08:31 +0000
        Re: Why can't I understand what coroutines are? Martijn van Buul <pino@dohd.org> - 2019-08-05 09:51 +0000
          Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-05 14:44 -0700
    Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-04 14:08 +0100
      Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-04 09:23 -0400
        Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-04 14:36 +0100
          Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-04 10:31 -0400
            Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-04 16:42 +0100
              Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-04 16:43 -0400
                Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-04 13:58 -0700
                  Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-04 17:36 -0400
                    Re: Why can't I understand what coroutines are? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-04 22:43 +0100
                    Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-04 22:52 +0100
                      Re: Why can't I understand what coroutines are? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-04 23:10 +0100
                      Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-04 21:32 -0400
                        Re: Why can't I understand what coroutines are? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-05 18:32 +0100
                          Re: Why can't I understand what coroutines are? scott@slp53.sl.home (Scott Lurndal) - 2019-08-05 17:48 +0000
                            Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-05 20:14 -0400
                            Re: Why can't I understand what coroutines are? leigh.v.johnston@googlemail.com - 2019-08-06 04:13 -0700
                              Re: Why can't I understand what coroutines are? leigh.v.johnston@googlemail.com - 2019-08-06 04:23 -0700
                                Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-06 22:19 +0100
                                  Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-06 15:19 -0700
                                    Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-07 00:01 +0100
                                      Re: Why can't I understand what coroutines are? scott@slp53.sl.home (Scott Lurndal) - 2019-08-06 23:52 +0000
                                      Re: Why can't I understand what coroutines are? Öö Tiib <ootiib@hot.ee> - 2019-08-06 16:57 -0700
                                        Re: Why can't I understand what coroutines are? scott@slp53.sl.home (Scott Lurndal) - 2019-08-07 14:41 +0000
                                          Re: Why can't I understand what coroutines are? Öö Tiib <ootiib@hot.ee> - 2019-08-08 07:10 -0700
                                    Re: Why can't I understand what coroutines are? scott@slp53.sl.home (Scott Lurndal) - 2019-08-06 23:49 +0000
                    Re: Why can't I understand what coroutines are? Robert Wessel <robertwessel2@yahoo.com> - 2019-08-04 22:04 -0500
                    Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-04 20:10 -0700
          Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-04 11:20 -0700
            Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-04 20:30 +0100
              Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-04 14:03 -0700
              Re: Why can't I understand what coroutines are? Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-05 09:36 +0300
                Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-05 14:34 -0700
          Re: Why can't I understand what coroutines are? scott@slp53.sl.home (Scott Lurndal) - 2019-08-04 19:46 +0000
        Re: Why can't I understand what coroutines are? Juha Nieminen <nospam@thanks.invalid> - 2019-08-05 08:37 +0000
          Re: Why can't I understand what coroutines are? David Brown <david.brown@hesbynett.no> - 2019-08-05 12:06 +0200
            Re: Why can't I understand what coroutines are? Juha Nieminen <nospam@thanks.invalid> - 2019-08-05 12:20 +0000
              Re: Why can't I understand what coroutines are? David Brown <david.brown@hesbynett.no> - 2019-08-06 15:06 +0200
                Re: Why can't I understand what coroutines are? David Brown <david.brown@hesbynett.no> - 2019-08-06 15:18 +0200
            Re: Why can't I understand what coroutines are? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-06 13:58 +0200
    Re: Why can't I understand what coroutines are? Sam <sam@email-scan.com> - 2019-08-04 09:17 -0400
    Re: Why can't I understand what coroutines are? Robert Wessel <robertwessel2@yahoo.com> - 2019-08-04 10:12 -0500
      Re: Why can't I understand what coroutines are? Juha Nieminen <nospam@thanks.invalid> - 2019-08-05 08:42 +0000
        Re: Why can't I understand what coroutines are? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-08-05 13:35 +0100
        Re: Why can't I understand what coroutines are? Bart <bc@freeuk.com> - 2019-08-05 20:19 +0100
        Re: Why can't I understand what coroutines are? Christian Gollwitzer <auriocus@gmx.de> - 2019-08-05 22:26 +0200
          Re: Why can't I understand what coroutines are? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-05 23:09 +0200
            Re: Why can't I understand what coroutines are? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-09 19:49 -0700
              Re: Why can't I understand what coroutines are? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-10 05:13 +0200
            Re: Why can't I understand what coroutines are? Christian Gollwitzer <auriocus@gmx.de> - 2019-08-10 08:23 +0200
              Re: Why can't I understand what coroutines are? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-10 10:43 +0200
                Re: Why can't I understand what coroutines are? Christian Gollwitzer <auriocus@gmx.de> - 2019-08-11 22:19 +0200
                  Re: Why can't I understand what coroutines are? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-14 08:25 -0700
          Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-10 00:19 -0700
          Re: Why can't I understand what coroutines are? Juha Nieminen <nospam@thanks.invalid> - 2019-08-11 21:16 +0000
        Re: Why can't I understand what coroutines are? "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> - 2019-08-05 23:43 -0700
        Re: Why can't I understand what coroutines are? Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-10 10:50 +0200
    Re: Why can't I understand what coroutines are? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-04 17:57 +0100
    Re: Why can't I understand what coroutines are? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-05 01:11 +0200
      Re: Why can't I understand what coroutines are? Juha Nieminen <nospam@thanks.invalid> - 2019-08-05 08:50 +0000
        Re: Why can't I understand what coroutines are? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-05 16:59 +0200
      Re: Why can't I understand what coroutines are? Manfred <noname@add.invalid> - 2019-08-06 16:24 +0200
      Re: Why can't I understand what coroutines are? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-08-07 00:52 +0200
        Re: Why can't I understand what coroutines are? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-08-09 18:11 -0700
    Re: Why can't I understand what coroutines are? Martijn van Buul <pino@dohd.org> - 2019-08-05 07:46 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#67316

On 05/08/2019 02:32, Sam wrote:
> Chris Vine writes:
> 
>> On Sun, 04 Aug 2019 17:36:12 -0400
>> Sam <sam@email-scan.com> wrote:
>>
>> > I agree that "a thread per connection simply does not scale" on Microsoft
>> > Windows. However that's only true for Microsoft Windows, and its crap
>> > multithreading.
>> >
>> > A thread per connection scales perfectly fine, on Linux. Even with 
>> hundreds
>> > of connections. Thread overhead is quite negligible on Linux, and you 
>> end up
>> > writing clean, orderly code that runs logically from start to finish,
>> > instead of getting torn into shreds in order to conform to event loop or
>> > callback-based design patterns.
>>
>> I disagree.  And "hundreds of connections" is not good enough.
> 
> You can disagree all you want. Historical facts prove otherwise. Since 
> ancient days, the simplest task on Unixes were done as pipelined tasks, as 
> multiple execution contexts.
> 
> $ sort <file | uniq -c
> 
> That dates back decades.From the earlier days, shells were explicitly 
> designed to execute pipelined commands. Pipelined commands were their main 
> feature. All of this is pretty much I/O bound. Multiple execution threads.
> 
> Because of that, and battle-tested over decades, Unix was tuned to 
> effortlessly implement tasks that use multiple processes working in 
> parallel. Threads were just the next evolution, dropping most of what 
> little was left, in terms of per-execution context overhead. Linux 
> inherited Unix's legacy, and orientation, towards low-overhead multiple 
> execution threads.
> 
> All the historical network server processes on Unix, then Linux, were 
> multi-processor based. Even though select() existed pretty much since 4.2 
> BSD days, it was virtually unheard of for a network server to be a 
> monolithic process, multiplexing for its clients using select(). An 
> incoming network connection starts a new process, just for that network 
> connection. Didn't matter what network service it was. SMTP, finger, 
> login, or what, it was all one process per connection.
> 
> There was a reason for that. It didn't take an Einstein to figure out that 
> with a monolithic server, once it picked up an I/O event it had to do what 
> that event needs to do, and nothing else can happen until that's done. 
> Even if another client blurted out a packet, too bad, so sad. It needs to 
> wait until the current I/O event's processing is done. It made a lot more 
> sense to simply have another available CPU, not being busy with anything, 
> run with it. And, goshdarndammit, if that socket had a different execution 
> thread sucking from it, why, that spare CPU will know exactly what to do.
> 
> So, monolithic processes were rare. They are a little bit more common 
> today than before, but they are still a rarity. And, today, even network 
> servers that kick off multiple processes per client can be found. So, 
> sorry, but facts disagree: multiple execution contexts, either as 
> standalone processes or lightweight intra-process threads rule the roost 
> in I/O bound contexts. Linux inherits Unix's legacy in this respect, and 
> the differences between processes and threads, on Linux, are mostly 
> cosmetic. clone() creates both of them. You just specify which part of the 
> parent process (virtual memory map, file descriptors, filesystem namespace 
> etc…) are shared with the new execution context, and that's pretty much.
> 
> I can understand why coming from a MS-Windows background makes someone 
> frown at execution threads, unless all they do is stay away from the 
> operating system, and work entirely on their own, spinning the CPU. The 
> only reason stuff like IOCP exists on Windows is because windows sucks at 
> multi-threading and multi-processing. It always sucked, and will likely 
> always suck.
> 
> But that's not the case with the real world out there. Being able to have 
> a clean, encapsulated, logical execution thread, always busy with the 
> forward march of progress from the start pointing to the finish line, 
> without being forced into contorting into an event/dispatch based 
> framework, results in smaller, leaner code without all that 
> event-based/dispatching cruft. It doesn't matter which one of the file 
> descriptors is now ready for I/O. It no longer matters. The OS kernel 
> already figured it out, and there's no good reason for userspace to piss 
> away more CPU cycles doing exactly the same thing. The OS kernel knows 
> which I/O is done, and which thread is waiting on it, and it already knows 
> whose ass to kick into gear.
> 
> A such, execution threads are perfect for I/O-based load. It is no wonder 
> that Linux rules the roost in TOP500 space. It's a dirty little secret 
> that all those supercomputers are just a bunch of machines with optimized 
> networking tying hundreds of thousands threads together. Yes, threads.
> 
> Gee whiz, how can that possibly happen?

epoll(...), dear.

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into 
snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who 
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – 
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are 
confronted by God," Bryne asked on his show The Meaning of Life. "What 
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery 
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a 
world that is so full of injustice and pain. That's what I would say."

[toc] | [prev] | [next] | [standalone]

#67317

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>On 05/08/2019 02:32, Sam wrote:
>> Chris Vine writes:

>> 
>> A such, execution threads are perfect for I/O-based load. It is no wonder 
>> that Linux rules the roost in TOP500 space. It's a dirty little secret 
>> that all those supercomputers are just a bunch of machines with optimized 
>> networking tying hundreds of thousands threads together. Yes, threads.
>> 
>> Gee whiz, how can that possibly happen?
>
>epoll(...), dear.
>

How does epoll help with high volume disk I/O?

[toc] | [prev] | [next] | [standalone]

#67323

[Multipart message — attachments visible in raw view] — view raw

Scott Lurndal writes:

> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
> >On 05/08/2019 02:32, Sam wrote:
> >> Chris Vine writes:
>
> >>
> >> A such, execution threads are perfect for I/O-based load. It is no wonder
> >> that Linux rules the roost in TOP500 space. It's a dirty little secret
> >> that all those supercomputers are just a bunch of machines with optimized
> >> networking tying hundreds of thousands threads together. Yes, threads.
> >>
> >> Gee whiz, how can that possibly happen?
> >
> >epoll(...), dear.
> >
>
> How does epoll help with high volume disk I/O?

Now look what you've done. You confused him with facts. Shame on you.

[toc] | [prev] | [next] | [standalone]

#67327

On Monday, August 5, 2019 at 6:48:18 PM UTC+1, Scott Lurndal wrote:
> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
> >On 05/08/2019 02:32, Sam wrote:
> >> Chris Vine writes:
> 
> >> 
> >> A such, execution threads are perfect for I/O-based load. It is no wonder 
> >> that Linux rules the roost in TOP500 space. It's a dirty little secret 
> >> that all those supercomputers are just a bunch of machines with optimized 
> >> networking tying hundreds of thousands threads together. Yes, threads.
> >> 
> >> Gee whiz, how can that possibly happen?
> >
> >epoll(...), dear.
> >
> 
> How does epoll help with high volume disk I/O?

How do threads help with high volume disk I/O, dear? 

[toc] | [prev] | [next] | [standalone]

#67328

On Tuesday, August 6, 2019 at 12:13:45 PM UTC+1, leigh.v...@googlemail.com wrote:
> On Monday, August 5, 2019 at 6:48:18 PM UTC+1, Scott Lurndal wrote:
> > Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
> > >On 05/08/2019 02:32, Sam wrote:
> > >> Chris Vine writes:
> > 
> > >> 
> > >> A such, execution threads are perfect for I/O-based load. It is no wonder 
> > >> that Linux rules the roost in TOP500 space. It's a dirty little secret 
> > >> that all those supercomputers are just a bunch of machines with optimized 
> > >> networking tying hundreds of thousands threads together. Yes, threads.
> > >> 
> > >> Gee whiz, how can that possibly happen?
> > >
> > >epoll(...), dear.
> > >
> > 
> > How does epoll help with high volume disk I/O?
> 
> How do threads help with high volume disk I/O, dear?

Of course by that I actually meant how does *lots* of threads help with high volume disk I /O, dear? 

[toc] | [prev] | [next] | [standalone]

#67337

On Tue, 6 Aug 2019 04:23:44 -0700 (PDT)
leigh.v.johnston@googlemail.com wrote:
> On Tuesday, August 6, 2019 at 12:13:45 PM UTC+1, leigh.v...@googlemail.com wrote:
> > On Monday, August 5, 2019 at 6:48:18 PM UTC+1, Scott Lurndal wrote:
> > > Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
> > > >On 05/08/2019 02:32, Sam wrote:
> > > >> Chris Vine writes:
> > > 
> > > >> 
> > > >> A such, execution threads are perfect for I/O-based load. It is no wonder 
> > > >> that Linux rules the roost in TOP500 space. It's a dirty little secret 
> > > >> that all those supercomputers are just a bunch of machines with optimized 
> > > >> networking tying hundreds of thousands threads together. Yes, threads.
> > > >> 
> > > >> Gee whiz, how can that possibly happen?
> > > >
> > > >epoll(...), dear.
> > > >
> > > 
> > > How does epoll help with high volume disk I/O?
> > 
> > How do threads help with high volume disk I/O, dear?
> 
> Of course by that I actually meant how does *lots* of threads help with
> high volume disk I /O, dear? 

No, you have fallen victim to a classic misdirection play by Scott.  The
claim made in response to a posting of mine, originally by someone by
the name of "Sam", was that native OS threads on linux (but not
windows) can deal equally well with the kind of i/o things that
coroutines are good at, and are easier to use.  Both these propositions
are in my opinion wrong, but it stands as the argument.

High volume disk i/o is irrelevant to this issue, because coroutines
aren't well suited to high volume disk i/o, nor are poll/select/epoll.
Native threads on the other hand are reasonably well suited to this work
load because operations on high volume disks tend to be cpu-bound and
not i/o-bound.  And apart from anything else, block devices representing
hard disks are always signalled as ready (at any rate, they are with
select and poll, I do not know about epoll, so poll and select are
useless with them).

The real answer to Scott is "how do coroutines help with high volume
disk i/o"?  I agree with what seems to be his suggestion - that they
don't - so they are irrelevant to your posting about epoll.

[toc] | [prev] | [next] | [standalone]

#67338

On 8/6/2019 2:19 PM, Chris Vine wrote:
> On Tue, 6 Aug 2019 04:23:44 -0700 (PDT)
> leigh.v.johnston@googlemail.com wrote:
>> On Tuesday, August 6, 2019 at 12:13:45 PM UTC+1, leigh.v...@googlemail.com wrote:
>>> On Monday, August 5, 2019 at 6:48:18 PM UTC+1, Scott Lurndal wrote:
>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>>>>> On 05/08/2019 02:32, Sam wrote:
>>>>>> Chris Vine writes:
>>>>
>>>>>>
>>>>>> A such, execution threads are perfect for I/O-based load. It is no wonder
>>>>>> that Linux rules the roost in TOP500 space. It's a dirty little secret
>>>>>> that all those supercomputers are just a bunch of machines with optimized
>>>>>> networking tying hundreds of thousands threads together. Yes, threads.
>>>>>>
>>>>>> Gee whiz, how can that possibly happen?
>>>>>
>>>>> epoll(...), dear.
>>>>>
>>>>
>>>> How does epoll help with high volume disk I/O?
>>>
>>> How do threads help with high volume disk I/O, dear?
>>
>> Of course by that I actually meant how does *lots* of threads help with
>> high volume disk I /O, dear?
> 
> No, you have fallen victim to a classic misdirection play by Scott.  The
> claim made in response to a posting of mine, originally by someone by
> the name of "Sam", was that native OS threads on linux (but not
> windows) can deal equally well with the kind of i/o things that
> coroutines are good at, and are easier to use.  Both these propositions
> are in my opinion wrong, but it stands as the argument.
> 
> High volume disk i/o is irrelevant to this issue, because coroutines
> aren't well suited to high volume disk i/o, nor are poll/select/epoll.
> Native threads on the other hand are reasonably well suited to this work
> load because operations on high volume disks tend to be cpu-bound and
> not i/o-bound.  And apart from anything else, block devices representing
> hard disks are always signalled as ready (at any rate, they are with
> select and poll, I do not know about epoll, so poll and select are
> useless with them).
> 
> The real answer to Scott is "how do coroutines help with high volume
> disk i/o"?  I agree with what seems to be his suggestion - that they
> don't - so they are irrelevant to your posting about epoll.
> 

AIO should be fine, its POSIX but oh well:

http://man7.org/linux/man-pages/man7/aio.7.html

https://pubs.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html

IOCP can be used with files, even memory mapped ones.

[toc] | [prev] | [next] | [standalone]

#67341

On Tue, 6 Aug 2019 15:19:48 -0700
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>
wrote: [snip]
> AIO should be fine, its POSIX but oh well:
> 
> http://man7.org/linux/man-pages/man7/aio.7.html
> 
> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html

Yes as I understand it AIO works for asynchronous i/o with block devices
representing hard disks, even though you can't use select/poll and I
think epoll for them.  But AIO is not my area and I have to say that I
can't really understand the point of it with disks: the issue with such
block devices is that in polling terms they are always available to
read or write in the absence of an error.  For reading in particular,
you don't do it for the fun of it: you do it to process the data you
obtain, which is likely to require use of the CPU.  So why not just use
threads without AIO?  You are not dealing with network latency.

I notice incidentally that the documentation for glibc's implementation
of AIO says: "This has a number of limitations, most notably that
maintaining multiple threads to perform I/O operations is expensive
and scales poorly".  All the more reason to do that particular work
synchronously I would have thought.  The alternative seems to be to use
signals.

Do you have any experience of AIO?  (As I say, I don't.)

[toc] | [prev] | [next] | [standalone]

#67343

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
>On Tue, 6 Aug 2019 15:19:48 -0700
>"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>
>wrote: [snip]
>> AIO should be fine, its POSIX but oh well:
>> 
>> http://man7.org/linux/man-pages/man7/aio.7.html
>> 
>> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html

>I notice incidentally that the documentation for glibc's implementation
>of AIO says: "This has a number of limitations, most notably that
>maintaining multiple threads to perform I/O operations is expensive
>and scales poorly".  All the more reason to do that particular work
>synchronously I would have thought.  The alternative seems to be to use
>signals.
>
>Do you have any experience of AIO?  (As I say, I don't.)

I used it on real unix extensively (mainly lio_listio()).   It's a good
way to let the operating system I/O scheduler handling the I/O in the
most efficient way and was quite efficient particularly with multiple
disk drives on multiple controllers.  Granted the application was
the oracle RDMS, for which the I/O requirements are not typical of
most applications.

[toc] | [prev] | [next] | [standalone]

#67344

On Wednesday, 7 August 2019 02:01:21 UTC+3, Chris Vine  wrote:
> But AIO is not my area and I have to say that I
> can't really understand the point of it with disks: the issue with such
> block devices is that in polling terms they are always available to
> read or write in the absence of an error.  For reading in particular,
> you don't do it for the fun of it: you do it to process the data you
> obtain, which is likely to require use of the CPU.  So why not just use
> threads without AIO?

It is better to use either async or blocking I/O but not to mix.
Translation between the two is possible to do with a thread. What 
difference there is if such translation from blocking to async I/O
was made by glibc or ourselves (other than less work for
ourselves when glibc did it)?

[toc] | [prev] | [next] | [standalone]

#67370

=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
>On Wednesday, 7 August 2019 02:01:21 UTC+3, Chris Vine  wrote:
>> But AIO is not my area and I have to say that I
>> can't really understand the point of it with disks: the issue with such
>> block devices is that in polling terms they are always available to
>> read or write in the absence of an error.  For reading in particular,
>> you don't do it for the fun of it: you do it to process the data you
>> obtain, which is likely to require use of the CPU.  So why not just use
>> threads without AIO?
>
>It is better to use either async or blocking I/O but not to mix.

For the same file descriptor or for the program?   why?

Use whatever is necessary to provide the required functionality
and performance.

>Translation between the two is possible to do with a thread. What 
>difference there is if such translation from blocking to async I/O
>was made by glibc or ourselves (other than less work for
>ourselves when glibc did it)?

What's wrong with using blocking I/O for some files and async I/O for
others?  (or even both on the same file, for that matter).

[toc] | [prev] | [next] | [standalone]

#67443

On Wednesday, 7 August 2019 17:41:47 UTC+3, Scott Lurndal  wrote:
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
> >On Wednesday, 7 August 2019 02:01:21 UTC+3, Chris Vine  wrote:
> >> But AIO is not my area and I have to say that I
> >> can't really understand the point of it with disks: the issue with such
> >> block devices is that in polling terms they are always available to
> >> read or write in the absence of an error.  For reading in particular,
> >> you don't do it for the fun of it: you do it to process the data you
> >> obtain, which is likely to require use of the CPU.  So why not just use
> >> threads without AIO?
> >
> >It is better to use either async or blocking I/O but not to mix.
> 
> For the same file descriptor or for the program?   why?

I meant for a single stream, regardless if it is file or something
else.

> Use whatever is necessary to provide the required functionality
> and performance.

Exactly.
With tiny files of size measured in kilobytes it is cheapest
and most robust to read whole file and then to process the data.
If that starts affect performance then the issue is keeping data
in too lot of too tiny files.
With bigger files when either reading or processing what was read is way
more expensive than other or both are inexpensive enough (for 
what is expected) then linear, blocking read and processing
cycle is good option. On case when it is large file and both cost of
reading and processing data affect performance then it is better
to keep input asynchronous and so to do these two things in parallel.

> >Translation between the two is possible to do with a thread. What 
> >difference there is if such translation from blocking to async I/O
> >was made by glibc or ourselves (other than less work for
> >ourselves when glibc did it)?
> 
> What's wrong with using blocking I/O for some files and async I/O for
> others?  (or even both on the same file, for that matter).

I know of no example where it was optimal for same file. 
I have experienced that attempts to mix the two for same file have
resulted with something pointlessly fragile and complicated. If
there is point to read parts of file asynchronously from processing
then switching between asynchronous and blocking mode have cost and
are complication. There have to be switching since file descriptors
that I've seen are not meant to do both at same time. Pointlessly
complex logic is then easier to break with maintenance. So it is
better to use blocking reads and to process the parts where processing
is expensive in separate threads instead.

[toc] | [prev] | [next] | [standalone]

#67342

"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com> writes:
>On 8/6/2019 2:19 PM, Chris Vine wrote:
>> On Tue, 6 Aug 2019 04:23:44 -0700 (PDT)
>> leigh.v.johnston@googlemail.com wrote:
>>> On Tuesday, August 6, 2019 at 12:13:45 PM UTC+1, leigh.v...@googlemail.com wrote:
>>>> On Monday, August 5, 2019 at 6:48:18 PM UTC+1, Scott Lurndal wrote:
>>>>> Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> writes:
>>>>>> On 05/08/2019 02:32, Sam wrote:
>>>>>>> Chris Vine writes:
>>>>>
>>>>>>>
>>>>>>> A such, execution threads are perfect for I/O-based load. It is no wonder
>>>>>>> that Linux rules the roost in TOP500 space. It's a dirty little secret
>>>>>>> that all those supercomputers are just a bunch of machines with optimized
>>>>>>> networking tying hundreds of thousands threads together. Yes, threads.
>>>>>>>
>>>>>>> Gee whiz, how can that possibly happen?
>>>>>>
>>>>>> epoll(...), dear.
>>>>>>
>>>>>
>>>>> How does epoll help with high volume disk I/O?
>>>>
>>>> How do threads help with high volume disk I/O, dear?
>>>
>>> Of course by that I actually meant how does *lots* of threads help with
>>> high volume disk I /O, dear?
>> 
>> No, you have fallen victim to a classic misdirection play by Scott.  The
>> claim made in response to a posting of mine, originally by someone by
>> the name of "Sam", was that native OS threads on linux (but not
>> windows) can deal equally well with the kind of i/o things that
>> coroutines are good at, and are easier to use.  Both these propositions
>> are in my opinion wrong, but it stands as the argument.
>> 
>> High volume disk i/o is irrelevant to this issue, because coroutines
>> aren't well suited to high volume disk i/o, nor are poll/select/epoll.
>> Native threads on the other hand are reasonably well suited to this work
>> load because operations on high volume disks tend to be cpu-bound and
>> not i/o-bound.  And apart from anything else, block devices representing
>> hard disks are always signalled as ready (at any rate, they are with
>> select and poll, I do not know about epoll, so poll and select are
>> useless with them).
>> 
>> The real answer to Scott is "how do coroutines help with high volume
>> disk i/o"?  I agree with what seems to be his suggestion - that they
>> don't - so they are irrelevant to your posting about epoll.
>> 
>
>AIO should be fine, its POSIX but oh well:
>
>http://man7.org/linux/man-pages/man7/aio.7.html

Indeed, and that's what I used in the Oracle RDMS os dependent code I wrote.
(well, technically, lio_listio() because we'd submit hundreds of
aiocbs with a single request - we had 128 physical disk drives on
64 SCSI controllers running Oracle Parallel Server on 64 tightly coupled
P6 processors running a distributed single-system-image micro-kernel
based operating system (written in C++, using cfront)).

Let the OS I/O subsystem do the scheduling, don't try to do it in user mode.

Note that modern network workloads that require high packet throughput
generally use DPDK which provides the capability to leverage any hardware
acceleration or offloading capabilities to improve I/O performance.  This
uses threads for parallelism.

https://www.dpdk.org/

Responding to Sam's assertion regarding the TOP 500; they, for the most
part, use Infiniband RDMA Verbs interface for communications between nodes,
not ethernet.   And it's all buried under openMP, PVM or other standard
communication library APIs integrated with C and C++.

[toc] | [prev] | [next] | [standalone]

#67294

On Sun, 04 Aug 2019 17:36:12 -0400, Sam <sam@email-scan.com> wrote:

>Chris M. Thomasson writes:
>
>> On 8/4/2019 1:43 PM, Sam wrote:
>>>> multiplex connections with poll/epoll/kqueue and tune the number of
>>>> threads to the workload and the number of cores available.
>>>
>>> Maybe you just don't know many people who write server code.
>>
>> I remember using IOCP back on WinNT 4. The idea of a thread per connection  
>> simply does not scale. However, creating a thread or two per CPU, and using  
>> a queue, like IOCP can scale.
>
>I agree that "a thread per connection simply does not scale" on Microsoft  
>Windows. However that's only true for Microsoft Windows, and its crap  
>multithreading.
>
>A thread per connection scales perfectly fine, on Linux. Even with hundreds  
>of connections. Thread overhead is quite negligible on Linux, and you end up  
>writing clean, orderly code that runs logically from start to finish,  
>instead of getting torn into shreds in order to conform to event loop or  
>callback-based design patterns.


If you only have "hundreds" of connections, use any technique you
like, scaling isn't an issue.

[toc] | [prev] | [next] | [standalone]

#67295

On 8/4/2019 2:36 PM, Sam wrote:
> Chris M. Thomasson writes:
> 
>> On 8/4/2019 1:43 PM, Sam wrote:
>>>> multiplex connections with poll/epoll/kqueue and tune the number of
>>>> threads to the workload and the number of cores available.
>>>
>>> Maybe you just don't know many people who write server code.
>>
>> I remember using IOCP back on WinNT 4. The idea of a thread per 
>> connection simply does not scale. However, creating a thread or two 
>> per CPU, and using a queue, like IOCP can scale.
> 
> I agree that "a thread per connection simply does not scale" on 
> Microsoft Windows. However that's only true for Microsoft Windows, and 
> its crap multithreading.
> 
> A thread per connection scales perfectly fine, on Linux. Even with 
> hundreds of connections. 

Hundreds? Try tens of thousands...

Back on WinNT 4.0, my server code could handle around 40,000 concurrent 
TCP connections, using a handful of threads.

There were bursts of activity, where many connections were being rapidly 
created and destroyed. My stress testing client programs tried to swamp 
the server with various scenarios. This was a long time ago.


> Thread overhead is quite negligible on Linux, 
> and you end up writing clean, orderly code that runs logically from 
> start to finish, instead of getting torn into shreds in order to conform 
> to event loop or callback-based design patterns.
> 

[toc] | [prev] | [next] | [standalone]

#67278

On 8/4/2019 6:36 AM, Chris Vine wrote:
> On Sun, 04 Aug 2019 09:23:52 -0400
> Sam <sam@email-scan.com> wrote:
>> Chris Vine writes:
>>
>>> Asynchronous programming with callbacks normally works so that when a
>>> i/o operation might block because the resource in question (read or
>>> write) is unavailable, instead of blocking the function returns
>>> immediately and registers a callback with the program's event loop
>>> (usually based on select() or poll()), representing the i/o operation's
>>> continuation when the resource becomes available.  Programming this way
>>> using callbacks in the style of, say, Node.js is troublesome because it
>>> gives rise to what is sometimes called inversion of control, aka
>>> "callback hell".  In particular, control flow ceases to appear as a
>>> sequential series of i/o operations which can easily be reasoned about.
>>
>> This problem was solved a long time ago. It is called "threads".
>>
>> The funniest thing about this is that Gnome is most extreme case of this.
>> The entire Gnome stack is just one event dispatching main loop. Everything
>> is callbacks. But since Gnome is C code, none of this will help it, that's
>> the funny part.
> 
> Threads are very definitely not the answer.  Threads work well with
> cpu-bound workloads.  They are hopeless with i/o-bound workloads, which
> is why co-operative (possibly single-threaded) multi-tasking using
> coroutines has become popular.
> 
> If you use native OS threads for i/o bound workloads, you are doing it
> wrong.
> 

Threads can work fairly well with IO, take a look at IOCP:

https://docs.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports

[toc] | [prev] | [next] | [standalone]

#67279

On Sun, 4 Aug 2019 11:20:51 -0700
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>
wrote:
> On 8/4/2019 6:36 AM, Chris Vine wrote:
> > On Sun, 04 Aug 2019 09:23:52 -0400
> > Sam <sam@email-scan.com> wrote:
> >> Chris Vine writes:
> >>
> >>> Asynchronous programming with callbacks normally works so that when a
> >>> i/o operation might block because the resource in question (read or
> >>> write) is unavailable, instead of blocking the function returns
> >>> immediately and registers a callback with the program's event loop
> >>> (usually based on select() or poll()), representing the i/o operation's
> >>> continuation when the resource becomes available.  Programming this way
> >>> using callbacks in the style of, say, Node.js is troublesome because it
> >>> gives rise to what is sometimes called inversion of control, aka
> >>> "callback hell".  In particular, control flow ceases to appear as a
> >>> sequential series of i/o operations which can easily be reasoned about.
> >>
> >> This problem was solved a long time ago. It is called "threads".
> >>
> >> The funniest thing about this is that Gnome is most extreme case of this.
> >> The entire Gnome stack is just one event dispatching main loop. Everything
> >> is callbacks. But since Gnome is C code, none of this will help it, that's
> >> the funny part.
> > 
> > Threads are very definitely not the answer.  Threads work well with
> > cpu-bound workloads.  They are hopeless with i/o-bound workloads, which
> > is why co-operative (possibly single-threaded) multi-tasking using
> > coroutines has become popular.
> >
> > If you use native OS threads for i/o bound workloads, you are doing it
> > wrong.
> > 
> 
> Threads can work fairly well with IO, take a look at IOCP:
> 
> https://docs.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports

I don't know microsoft's implementations, but as far as I can make out
the i/o is still done asynchronously (the file operations themselves do
not block) but when an asynchronous operation completes that completion
is handled by the completion port.  Although threads can wait on the
completion port for an i/o operation to reach completion, there appears
to be some form of multiplexing so that one thread can handle a number
of completions, and the documentation suggests that having a number of
threads equal to the number of cores (as opposed to the number of
connections) as a good starting point, which seems reasonable.

But I cannot say the documentation you refer to is that clear: is my
summary wrong (and if so, what's the point of completion ports in the
first place)?  I find it hard to believe microsoft would have gone for
the one thread per connection option favoured by my respondent.

[toc] | [prev] | [next] | [standalone]

#67284

On 8/4/2019 12:30 PM, Chris Vine wrote:
> On Sun, 4 Aug 2019 11:20:51 -0700
> "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>
> wrote:
>> On 8/4/2019 6:36 AM, Chris Vine wrote:
>>> On Sun, 04 Aug 2019 09:23:52 -0400
>>> Sam <sam@email-scan.com> wrote:
>>>> Chris Vine writes:
>>>>
>>>>> Asynchronous programming with callbacks normally works so that when a
>>>>> i/o operation might block because the resource in question (read or
>>>>> write) is unavailable, instead of blocking the function returns
>>>>> immediately and registers a callback with the program's event loop
>>>>> (usually based on select() or poll()), representing the i/o operation's
>>>>> continuation when the resource becomes available.  Programming this way
>>>>> using callbacks in the style of, say, Node.js is troublesome because it
>>>>> gives rise to what is sometimes called inversion of control, aka
>>>>> "callback hell".  In particular, control flow ceases to appear as a
>>>>> sequential series of i/o operations which can easily be reasoned about.
>>>>
>>>> This problem was solved a long time ago. It is called "threads".
>>>>
>>>> The funniest thing about this is that Gnome is most extreme case of this.
>>>> The entire Gnome stack is just one event dispatching main loop. Everything
>>>> is callbacks. But since Gnome is C code, none of this will help it, that's
>>>> the funny part.
>>>
>>> Threads are very definitely not the answer.  Threads work well with
>>> cpu-bound workloads.  They are hopeless with i/o-bound workloads, which
>>> is why co-operative (possibly single-threaded) multi-tasking using
>>> coroutines has become popular.
>>>
>>> If you use native OS threads for i/o bound workloads, you are doing it
>>> wrong.
>>>
>>
>> Threads can work fairly well with IO, take a look at IOCP:
>>
>> https://docs.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports
> 
> I don't know microsoft's implementations, but as far as I can make out
> the i/o is still done asynchronously (the file operations themselves do
> not block) but when an asynchronous operation completes that completion
> is handled by the completion port.  Although threads can wait on the
> completion port for an i/o operation to reach completion, there appears
> to be some form of multiplexing so that one thread can handle a number
> of completions, and the documentation suggests that having a number of
> threads equal to the number of cores (as opposed to the number of
> connections) as a good starting point, which seems reasonable.
> 
> But I cannot say the documentation you refer to is that clear: is my
> summary wrong (and if so, what's the point of completion ports in the
> first place)?  I find it hard to believe microsoft would have gone for
> the one thread per connection option favoured by my respondent.
> 

You treat each connection as a little state machine. This state has a 
socket, file, whatever, along with a memory buffer, or a pointer into 
some memory for io. It gets associated with the IOCP. Create several 
worker threads, one or two per CPU, and set the concurrency level to the 
number of CPUs. Now, worker threads wait on the IOCP for events. Each 
event has the state of the connection. If a read event fires, the memory 
buffer has the data, or there might be an error, whatever.

Actually, imvho, creating servers with IOCP is fairly straightforward.

[toc] | [prev] | [next] | [standalone]

#67296

On 4.08.2019 22:30, Chris Vine wrote:
> On Sun, 4 Aug 2019 11:20:51 -0700
> "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>
> wrote:
>> On 8/4/2019 6:36 AM, Chris Vine wrote:
>>> On Sun, 04 Aug 2019 09:23:52 -0400
>>> Sam <sam@email-scan.com> wrote:
>>>> Chris Vine writes:
>>>>
>>>>> Asynchronous programming with callbacks normally works so that when a
>>>>> i/o operation might block because the resource in question (read or
>>>>> write) is unavailable, instead of blocking the function returns
>>>>> immediately and registers a callback with the program's event loop
>>>>> (usually based on select() or poll()), representing the i/o operation's
>>>>> continuation when the resource becomes available.  Programming this way
>>>>> using callbacks in the style of, say, Node.js is troublesome because it
>>>>> gives rise to what is sometimes called inversion of control, aka
>>>>> "callback hell".  In particular, control flow ceases to appear as a
>>>>> sequential series of i/o operations which can easily be reasoned about.
>>>>
>>>> This problem was solved a long time ago. It is called "threads".
>>>>
>>>> The funniest thing about this is that Gnome is most extreme case of this.
>>>> The entire Gnome stack is just one event dispatching main loop. Everything
>>>> is callbacks. But since Gnome is C code, none of this will help it, that's
>>>> the funny part.
>>>
>>> Threads are very definitely not the answer.  Threads work well with
>>> cpu-bound workloads.  They are hopeless with i/o-bound workloads, which
>>> is why co-operative (possibly single-threaded) multi-tasking using
>>> coroutines has become popular.
>>>
>>> If you use native OS threads for i/o bound workloads, you are doing it
>>> wrong.
>>>
>>
>> Threads can work fairly well with IO, take a look at IOCP:
>>
>> https://docs.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports
>
> I don't know microsoft's implementations, but as far as I can make out
> the i/o is still done asynchronously (the file operations themselves do
> not block) but when an asynchronous operation completes that completion
> is handled by the completion port.  Although threads can wait on the
> completion port for an i/o operation to reach completion, there appears
> to be some form of multiplexing so that one thread can handle a number
> of completions, and the documentation suggests that having a number of
> threads equal to the number of cores (as opposed to the number of
> connections) as a good starting point, which seems reasonable.
>
> But I cannot say the documentation you refer to is that clear: is my
> summary wrong (and if so, what's the point of completion ports in the
> first place)?  I find it hard to believe microsoft would have gone for
> the one thread per connection option favoured by my respondent.

IOCP is used in Windows to *reduce* the number of needed threads (at 
least in user space), which is important because in Windows the thread 
creation is a pretty heavyweight operation. So it's strange that IOCP is 
mentioned as an example of "Threads can work fairly well with IO", it's 
rather the opposite, at least on Windows.

The Linux equivalent of IOCP is AIO, see e.g. "man aio_read". However, 
some googling suggests the Linux implementation is not yet optimal (I 
guess this means it is not yet built into the kernel to the same extent 
as in Windows).

Also, the popular Boost.Asio library has "asynchronous" already in its 
name and uses async IO in the background as appropriate. It also has 
implementations of coroutines, so maybe one can study its documentation 
and examples in order to get familiar with coroutines.

BTW, Boost.Asio does not create a "thread per connection". Vice versa, 
it expects the client program to set up a thread pool (with the number 
of threads based on the number of cores, typically) which is reused for 
all requests.

[toc] | [prev] | [next] | [standalone]

#67321

On 8/4/2019 11:36 PM, Paavo Helde wrote:
> On 4.08.2019 22:30, Chris Vine wrote:
>> On Sun, 4 Aug 2019 11:20:51 -0700
>> "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>
>> wrote:
>>> On 8/4/2019 6:36 AM, Chris Vine wrote:
>>>> On Sun, 04 Aug 2019 09:23:52 -0400
>>>> Sam <sam@email-scan.com> wrote:
>>>>> Chris Vine writes:
>>>>>
>>>>>> Asynchronous programming with callbacks normally works so that when a
>>>>>> i/o operation might block because the resource in question (read or
>>>>>> write) is unavailable, instead of blocking the function returns
>>>>>> immediately and registers a callback with the program's event loop
>>>>>> (usually based on select() or poll()), representing the i/o 
>>>>>> operation's
>>>>>> continuation when the resource becomes available.  Programming 
>>>>>> this way
>>>>>> using callbacks in the style of, say, Node.js is troublesome 
>>>>>> because it
>>>>>> gives rise to what is sometimes called inversion of control, aka
>>>>>> "callback hell".  In particular, control flow ceases to appear as a
>>>>>> sequential series of i/o operations which can easily be reasoned 
>>>>>> about.
>>>>>
>>>>> This problem was solved a long time ago. It is called "threads".
>>>>>
>>>>> The funniest thing about this is that Gnome is most extreme case of 
>>>>> this.
>>>>> The entire Gnome stack is just one event dispatching main loop. 
>>>>> Everything
>>>>> is callbacks. But since Gnome is C code, none of this will help it, 
>>>>> that's
>>>>> the funny part.
>>>>
>>>> Threads are very definitely not the answer.  Threads work well with
>>>> cpu-bound workloads.  They are hopeless with i/o-bound workloads, which
>>>> is why co-operative (possibly single-threaded) multi-tasking using
>>>> coroutines has become popular.
>>>>
>>>> If you use native OS threads for i/o bound workloads, you are doing it
>>>> wrong.
>>>>
>>>
>>> Threads can work fairly well with IO, take a look at IOCP:
>>>
>>> https://docs.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports 
>>>
>>
>> I don't know microsoft's implementations, but as far as I can make out
>> the i/o is still done asynchronously (the file operations themselves do
>> not block) but when an asynchronous operation completes that completion
>> is handled by the completion port.  Although threads can wait on the
>> completion port for an i/o operation to reach completion, there appears
>> to be some form of multiplexing so that one thread can handle a number
>> of completions, and the documentation suggests that having a number of
>> threads equal to the number of cores (as opposed to the number of
>> connections) as a good starting point, which seems reasonable.
>>
>> But I cannot say the documentation you refer to is that clear: is my
>> summary wrong (and if so, what's the point of completion ports in the
>> first place)?  I find it hard to believe microsoft would have gone for
>> the one thread per connection option favoured by my respondent.
> 
> IOCP is used in Windows to *reduce* the number of needed threads (at 
> least in user space), which is important because in Windows the thread 
> creation is a pretty heavyweight operation. So it's strange that IOCP is 
> mentioned as an example of "Threads can work fairly well with IO", it's 
> rather the opposite, at least on Windows.

Yeah. IOCP is the way to do things on Windows wrt creating scaleable 
servers. I am fond of the following function:

https://docs.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-transmitfile

It works well with IOCP. Also,

https://docs.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_transmitpackets

There is a neat way to wait on IOCP that can dequeue several events in 
one shot:

https://docs.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func

Iirc, certain Windows os's limited the number of TransmitFile functions 
to a max of two concurrent inflight calls at any time. The server 
versions of the OS would allow for as many as the system could handle at 
a time.



> 
> The Linux equivalent of IOCP is AIO, see e.g. "man aio_read". However, 
> some googling suggests the Linux implementation is not yet optimal (I 
> guess this means it is not yet built into the kernel to the same extent 
> as in Windows).
> 
> Also, the popular Boost.Asio library has "asynchronous" already in its 
> name and uses async IO in the background as appropriate. It also has 
> implementations of coroutines, so maybe one can study its documentation 
> and examples in order to get familiar with coroutines.
> 
> BTW, Boost.Asio does not create a "thread per connection". Vice versa, 
> it expects the client program to set up a thread pool (with the number 
> of threads based on the number of cores, typically) which is reused for 
> all requests.
> 
> 

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web