I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
On 6/30/2026 1:27 AM, Wuns Haerst wrote:
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Well, we should never be creating threads all the time and joining them, >ect. Just make a nice thread pool up front. Adding more threads to it
should be fairly rare.
The lowest overhead existing solution, to my knowledge, is
"protothreads". C++ has standardised support for coroutines, though it
is a bit clunky as a late addition to the language. Go has goroutines
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Am 30.06.2026 um 16:14 schrieb Scott Lurndal:
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Fiber-like context-switchs are *much* faster than through the kernel.
The problem with that is you don't have any context switchs among
your "threads" when you run kernel-code.
Oracle does user-level scheduling and solves the kernel-issue by
never calling any blocking kernel-calls.
Wuns Haerst <Wuns.Haerst@wurstfabrik.at> writes:
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
On Tue, 30 Jun 2026 14:14:47 GMT
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Java of course being a prime example with its green threads.
Am 30.06.2026 um 17:39 schrieb boltar@caprica.universe:
On Tue, 30 Jun 2026 14:14:47 GMT
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Java of course being a prime example with its green threads.
According to Wikipedia Java had green threads between 1997 and 2000.
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Wuns Haerst <Wuns.Haerst@wurstfabrik.at> writes:
Am 30.06.2026 um 17:39 schrieb boltar@caprica.universe:
On Tue, 30 Jun 2026 14:14:47 GMT
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Java of course being a prime example with its green threads.
According to Wikipedia Java had green threads between 1997 and 2000.
Only on linux. Java on SunOS/Solaris/Unixware used Unix[*] threads.
On Tue, 30 Jun 2026 01:42:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 1:27 AM, Wuns Haerst wrote:
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Well, we should never be creating threads all the time and joining
them, ect. Just make a nice thread pool up front. Adding more threads
to it should be fairly rare.
"Just make a threadpool" is a non trivial coding task and completely unnecessary for programs that only create threads ad hoc now and then. If you're writing a high throughput server then sure, otherwise no.
On Tue, 30 Jun 2026 11:07:36 +0200
David Brown <david.brown@hesbynett.no> gabbled:
The lowest overhead existing solution, to my knowledge, is
"protothreads".ÿ C++ has standardised support for coroutines, though
it is a bit clunky as a late addition to the language.ÿ Go has goroutines
They're a badly specced solution looking for a problem whose logic can already
be solved with function static autos and/or thread local vars.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 30.06.2026 um 16:14 schrieb Scott Lurndal:
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Fiber-like context-switchs are *much* faster than through the kernel.
The problem with that is you don't have any context switchs among
your "threads" when you run kernel-code.
Oracle does user-level scheduling and solves the kernel-issue by
never calling any blocking kernel-calls.
How do you know how the oracle RDBMS works internally?
(I did spend some time working with the RDBMS sources in the 90s).
On 6/30/2026 3:44 AM, boltar@caprica.universe wrote:
On Tue, 30 Jun 2026 01:42:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 1:27 AM, Wuns Haerst wrote:
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Well, we should never be creating threads all the time and joining
them, ect. Just make a nice thread pool up front. Adding more threads
to it should be fairly rare.
"Just make a threadpool" is a non trivial coding task and completely
unnecessary for programs that only create threads ad hoc now and then. If
you're writing a high throughput server then sure, otherwise no.
Thread pools are not all that hard. Since you are using threads anyway,
how are you handling the sync in your program logic to them? What do
they do?
On 6/30/2026 3:46 AM, boltar@caprica.universe wrote:
On Tue, 30 Jun 2026 11:07:36 +0200
David Brown <david.brown@hesbynett.no> gabbled:
The lowest overhead existing solution, to my knowledge, isThey're a badly specced solution looking for a problem whose logic can
"protothreads".ÿ C++ has standardised support for coroutines, though
it is a bit clunky as a late addition to the language.ÿ Go has goroutines >>
already
be solved with function static autos and/or thread local vars.
How much experience do you have with per_thread data?
On Wed, 1 Jul 2026 12:23:45 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 3:44 AM, boltar@caprica.universe wrote:
On Tue, 30 Jun 2026 01:42:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 1:27 AM, Wuns Haerst wrote:
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Well, we should never be creating threads all the time and joining
them, ect. Just make a nice thread pool up front. Adding more
threads to it should be fairly rare.
"Just make a threadpool" is a non trivial coding task and completely
unnecessary for programs that only create threads ad hoc now and
then. If
you're writing a high throughput server then sure, otherwise no.
Thread pools are not all that hard. Since you are using threads anyway,
They're hard enough to make it a lot of pointless work if its not
necessary. As I said, if you're creating threads every few milliseconds
then
use a thread pool. If you're just creating a thread every few seconds or longer then a pool is a complete waste of time.
how are you handling the sync in your program logic to them? What do
they do?
Is that supposed to be some kind of trick question?
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
They're hard enough to make it a lot of pointless work if its not
necessary. As I said, if you're creating threads every few milliseconds
then
use a thread pool. If you're just creating a thread every few seconds or
longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be it. >Just don't be alarmed if you get 10000 threads all of sudden. Or, say a >connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
how are you handling the sync in your program logic to them? What do
they do?
Is that supposed to be some kind of trick question?
No. It means how to you say, join them, or are you detaching them? How
can you gain data from them? You need to know all about this if you are >going to use threads at all. Well, imvho that is...
Do you have a "reaper" thread that can conduct "maintenance"? Zombie
states? Are you do graceful shutdowns?
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, so be it. >>Just don't be alarmed if you get 10000 threads all of sudden. Or, say a >>connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes far more >CPU resources than simply adding a new program counter into the scheduler >list, right?
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, so be it. >>>Just don't be alarmed if you get 10000 threads all of sudden. Or, say a >>>connection comes in every second for say a half an hour. 1800 >>>connections? Also you need to think about a connection that sends a >>>little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes far more >>CPU resources than simply adding a new program counter into the scheduler >>list, right?
You're clearly not an expert on operating systems. There's far
more involved than "simply adding a new program counter to the scheduler list" >during thread creation.
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
On Wed, 1 Jul 2026 12:23:45 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 3:44 AM, boltar@caprica.universe wrote:
On Tue, 30 Jun 2026 01:42:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 1:27 AM, Wuns Haerst wrote:
I measured the time it takes to create a thread on both Windows and >>>>>> Linux. On Windows, it takes around 120,000 clock cycles, whereas on >>>>>> Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its >>>>>> runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just >>>>>> not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
Well, we should never be creating threads all the time and joining
them, ect. Just make a nice thread pool up front. Adding more
threads to it should be fairly rare.
"Just make a threadpool" is a non trivial coding task and completely
unnecessary for programs that only create threads ad hoc now and
then. If
you're writing a high throughput server then sure, otherwise no.
Thread pools are not all that hard. Since you are using threads anyway,
They're hard enough to make it a lot of pointless work if its not
necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few seconds
or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be it.
Just don't be alarmed if you get 10000 threads all of sudden. Or, say a connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
how are you handling the sync in your program logic to them? What do
they do?
Is that supposed to be some kind of trick question?
No. It means how to you say, join them, or are you detaching them? How
can you gain data from them? You need to know all about this if you are
going to use threads at all. Well, imvho that is...
Do you have a "reaper" thread that can conduct "maintenance"? Zombie
states? Are you do graceful shutdowns?
On 07/02/2026 11:41 AM, Chris M. Thomasson wrote:
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
On Wed, 1 Jul 2026 12:23:45 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 3:44 AM, boltar@caprica.universe wrote:They're hard enough to make it a lot of pointless work if its not
On Tue, 30 Jun 2026 01:42:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 6/30/2026 1:27 AM, Wuns Haerst wrote:
I measured the time it takes to create a thread on both Windows and >>>>>>> Linux. On Windows, it takes around 120,000 clock cycles, whereas on >>>>>>> Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main >>>>>>> function. This would eliminate the need for the operating system >>>>>>> call to create the thread. In this scenario, the compiler ? or its >>>>>>> runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to >>>>>>> just a few clock cycles, making thread pools unnecessary. I?m just >>>>>>> not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend >>>>>>> to patent this idea once it is fully developed.
Well, we should never be creating threads all the time and joining >>>>>> them, ect. Just make a nice thread pool up front. Adding more
threads to it should be fairly rare.
"Just make a threadpool" is a non trivial coding task and completely >>>>> unnecessary for programs that only create threads ad hoc now and
then. If
you're writing a high throughput server then sure, otherwise no.
Thread pools are not all that hard. Since you are using threads anyway, >>>
necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few seconds
or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be it.
Just don't be alarmed if you get 10000 threads all of sudden. Or, say a
connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
how are you handling the sync in your program logic to them? What do
they do?
Is that supposed to be some kind of trick question?
No. It means how to you say, join them, or are you detaching them? How
can you gain data from them? You need to know all about this if you are
going to use threads at all. Well, imvho that is...
Do you have a "reaper" thread that can conduct "maintenance"? Zombie
states? Are you do graceful shutdowns?
"Sweeper" usually it's called, here, for the case of timeouts.
Have you heard of re-routines? It's a model of co-operative
multi-threading with async everywhere yet written in the language as procedural flow of control with exceptions, thusly "async" nowhere.
Have you heard of re-routines? ....
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
They're hard enough to make it a lot of pointless work if its not
necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few seconds
or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be
it. Just don't be alarmed if you get 10000 threads all of sudden. Or,
say a connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes far more CPU resources than simply adding a new program counter into the scheduler list, right? If we were talking about creating a new process via fork()
then
your argument might have some merit, but threads? No.
how are you handling the sync in your program logic to them? What do
they do?
Is that supposed to be some kind of trick question?
No. It means how to you say, join them, or are you detaching them? How
can you gain data from them? You need to know all about this if you
are going to use threads at all. Well, imvho that is...
I would imagine most threads in a server process run detached. Joining
makes
little sense unless you specifically need to wait for the thread to
complete
its task in which case there might be an argument for doing the task sequentially anyway.
Do you have a "reaper" thread that can conduct "maintenance"? Zombie
states? Are you do graceful shutdowns?
I'd hate to see your code, must be an overcomplicated mess.
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to sketch
out an IOCP server setup from my memory... It should compile for you, I
will show my ralloc code in follow up. I had a little trouble
On Fri, 3 Jul 2026 12:44:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to sketch
out an IOCP server setup from my memory... It should compile for you, I
Are you seriously expecting me to believe you spent a morning writing the 1200 lines of code below from memory? Oh please.
Also it looks like win32 code and AFAIK windows for [reasons] can't do multiplexing on sockets so you have the ridiculous situation of needing a thread per connection whether you like it or not.
will show my ralloc code in follow up. I had a little trouble
Don't bother, don't care, I have better things to do than wade through all that code. Provide a 20 line example of "simple" thread pools and I might
be interested.
On 7/4/2026 2:16 AM, boltar@caprica.universe wrote:
On Fri, 3 Jul 2026 12:44:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to
sketch out an IOCP server setup from my memory... It should compile
for you, I
Are you seriously expecting me to believe you spent a morning writing the
1200 lines of code below from memory? Oh please.
Several days on some free time, yes, from memory.
Also it looks like win32 code and AFAIK windows for [reasons] can't do
multiplexing on sockets so you have the ridiculous situation of needing a
thread per connection whether you like it or not.
Huh? When is the last time you used GetQueuedCompletionStatusEx?
will show my ralloc code in follow up. I had a little trouble
Don't bother, don't care, I have better things to do than wade through
all
that code. Provide a 20 line example of "simple" thread pools and I might
be interested.
My ralloc code? Its pretty old! Yet works like a charm.
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
They're hard enough to make it a lot of pointless work if its not
necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few seconds
or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be
it. Just don't be alarmed if you get 10000 threads all of sudden. Or,
say a connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes far more CPU resources than simply adding a new program counter into the scheduler list, right? If we were talking about creating a new process via fork()
then
your argument might have some merit, but threads? No.
On Tue, 30 Jun 2026 10:27:38 +0200
Wuns Haerst <Wuns.Haerst@wurstfabrik.at> wrote:
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
In majority of situations you don't need to create threads on Window.
Use one of the several available Windows thread pool APIs.
For example, QueueUserWorkItem() - somewhat outdated and not
feature-rich, but very easy to use.
Of course, in C++ group it is of topic, because it does not map itself
well into C++ std::thread model. But that should not stop you if it is
a right answer to youur needs.
On 7/4/2026 2:16 AM, boltar@caprica.universe wrote:
On Fri, 3 Jul 2026 12:44:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to sketch
out an IOCP server setup from my memory... It should compile for you, I
Are you seriously expecting me to believe you spent a morning writing the
1200 lines of code below from memory? Oh please.
Several days on some free time, yes, from memory.
Also it looks like win32 code and AFAIK windows for [reasons] can't do
multiplexing on sockets so you have the ridiculous situation of needing a
thread per connection whether you like it or not.
Huh? When is the last time you used GetQueuedCompletionStatusEx?
Don't bother, don't care, I have better things to do than wade through all >> that code. Provide a 20 line example of "simple" thread pools and I might
be interested.
My ralloc code? Its pretty old! Yet works like a charm.
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
They're hard enough to make it a lot of pointless work if its not
necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few seconds >>>> or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be
it. Just don't be alarmed if you get 10000 threads all of sudden. Or,
say a connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes far more >> CPU resources than simply adding a new program counter into the scheduler
list, right? If we were talking about creating a new process via fork()
then
your argument might have some merit, but threads? No.
Why destroy the socket? Reuse it:
TF_REUSE_SOCKET
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-mswsock-lpfn_dis
connectex
On Sat, 4 Jul 2026 17:32:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/4/2026 2:16 AM, boltar@caprica.universe wrote:
On Fri, 3 Jul 2026 12:44:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to
sketch out an IOCP server setup from my memory... It should compile
for you, I
Are you seriously expecting me to believe you spent a morning writing
the
1200 lines of code below from memory? Oh please.
Several days on some free time, yes, from memory.
What an exiting life you must have.
Also it looks like win32 code and AFAIK windows for [reasons] can't do
multiplexing on sockets so you have the ridiculous situation of
needing a
thread per connection whether you like it or not.
Huh? When is the last time you used GetQueuedCompletionStatusEx?
Never even heard of it. Can it also multiplex file descriptors + std in,out,err
in the same call like select() or poll()? No, didn't think so, so you'll still
need multiple threads if you want to do all at the same time. Good old half assed win32.
Don't bother, don't care, I have better things to do than wade
through all
that code. Provide a 20 line example of "simple" thread pools and I
might
be interested.
My ralloc code? Its pretty old! Yet works like a charm.
So show a short example in 20 lines or less then if its as "simple" as you claim.
On Sat, 4 Jul 2026 23:36:09 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
They're hard enough to make it a lot of pointless work if its not
necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few
seconds or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be
it. Just don't be alarmed if you get 10000 threads all of sudden.
Or, say a connection comes in every second for say a half an hour.
1800 connections? Also you need to think about a connection that
sends a little data then just sits there doing nothing for say 20
minutes.
You do realise setting up and pulling down a TCP connection takes far
more
CPU resources than simply adding a new program counter into the
scheduler
list, right? If we were talking about creating a new process via
fork() then
your argument might have some merit, but threads? No.
Why destroy the socket? Reuse it:
TF_REUSE_SOCKET
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-
mswsock-lpfn_dis
connectex
I'm not interesting in win32, I only do posix and in posix a socket is simply
an (indirect) integer index into a kernel network connection. Re-using
one after
the network connection has been closed makes no sense.
How do you know how the oracle RDBMS works internally?
On 7/5/2026 1:21 AM, boltar@caprica.universe wrote:
I'm not interesting in win32, I only do posix and in posix a socket is
simply
an (indirect) integer index into a kernel network connection. Re-using
one after
the network connection has been closed makes no sense.
Why? TF_REUSE_SOCKET is VERY useful.
Am 30.06.2026 um 17:25 schrieb Scott Lurndal:
How do you know how the oracle RDBMS works internally?
It's not documented but a lot of people have guessed that.
Oracle
allows it to limit the absolute CPU-time of a session, a user or
a consumer group. With Windows this isn't possible so you have
to do our own userspace schedulung. With Linux it's possible
since Linux has control groups, but Oracle predates this feature.
On 7/5/2026 1:19 AM, boltar@caprica.universe wrote:
On Sat, 4 Jul 2026 17:32:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/4/2026 2:16 AM, boltar@caprica.universe wrote:
On Fri, 3 Jul 2026 12:44:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to
sketch out an IOCP server setup from my memory... It should compile >>>>> for you, I
Are you seriously expecting me to believe you spent a morning writing >>>> the
1200 lines of code below from memory? Oh please.
Several days on some free time, yes, from memory.
What an exiting life you must have.
Also it looks like win32 code and AFAIK windows for [reasons] can't do >>>> multiplexing on sockets so you have the ridiculous situation of
needing a
thread per connection whether you like it or not.
Huh? When is the last time you used GetQueuedCompletionStatusEx?
Never even heard of it. Can it also multiplex file descriptors + std
in,out,err
in the same call like select() or poll()? No, didn't think so, so you'll
still
need multiple threads if you want to do all at the same time. Good old half >> assed win32.
Huh? It can work with SOCKETS and FILES.
So show a short example in 20 lines or less then if its as "simple" as you >> claim.
Huh? My ralloc code or a thread pool?
On 7/5/2026 1:21 AM, boltar@caprica.universe wrote:
On Sat, 4 Jul 2026 23:36:09 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
They're hard enough to make it a lot of pointless work if its not >>>>>> necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few
seconds or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so be >>>>> it. Just don't be alarmed if you get 10000 threads all of sudden.
Or, say a connection comes in every second for say a half an hour.
1800 connections? Also you need to think about a connection that
sends a little data then just sits there doing nothing for say 20
minutes.
You do realise setting up and pulling down a TCP connection takes far >>>> more
CPU resources than simply adding a new program counter into the
scheduler
list, right? If we were talking about creating a new process via
fork() then
your argument might have some merit, but threads? No.
Why destroy the socket? Reuse it:
TF_REUSE_SOCKET
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-
mswsock-lpfn_dis
connectex
I'm not interesting in win32, I only do posix and in posix a socket is
simply
an (indirect) integer index into a kernel network connection. Re-using
one after
the network connection has been closed makes no sense.
Why? TF_REUSE_SOCKET is VERY useful.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 7/5/2026 1:21 AM, boltar@caprica.universe wrote:
I'm not interesting in win32, I only do posix and in posix a socket is
simply
an (indirect) integer index into a kernel network connection. Re-using
one after
the network connection has been closed makes no sense.
Why? TF_REUSE_SOCKET is VERY useful.
Posix has SO_REUSEADDR and SO_REUSEPORT for socket reuse.
Bonita Montero <Bonita.Montero@gmail.com> writes:
It's not documented but a lot of people have guessed that.
So you don't know.
Oracle
allows it to limit the absolute CPU-time of a session, a user or
a consumer group. With Windows this isn't possible so you have
to do our own userspace schedulung. With Linux it's possible
since Linux has control groups, but Oracle predates this feature.
Process resource limits have been available in Unix since before
DOS morphed into windows 3.1.
On Sun, 5 Jul 2026 01:21:56 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 1:19 AM, boltar@caprica.universe wrote:
On Sat, 4 Jul 2026 17:32:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/4/2026 2:16 AM, boltar@caprica.universe wrote:
On Fri, 3 Jul 2026 12:44:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to
sketch out an IOCP server setup from my memory... It should
compile for you, I
Are you seriously expecting me to believe you spent a morning
writing the
1200 lines of code below from memory? Oh please.
Several days on some free time, yes, from memory.
What an exiting life you must have.
Also it looks like win32 code and AFAIK windows for [reasons] can't do >>>>> multiplexing on sockets so you have the ridiculous situation of
needing a
thread per connection whether you like it or not.
Huh? When is the last time you used GetQueuedCompletionStatusEx?
Never even heard of it. Can it also multiplex file descriptors + std
in,out,err
in the same call like select() or poll()? No, didn't think so, so
you'll still
need multiple threads if you want to do all at the same time. Good
old half
assed win32.
Huh? It can work with SOCKETS and FILES.
Well thats nice. What about pipes, fifos and character and block devices?
Of course if they'd use the interface that was standard even when they
were developing win32 it would have been more useful.
So show a short example in 20 lines or less then if its as "simple"
as you
claim.
Huh? My ralloc code or a thread pool?
A thread pool, I have no idea what your ralloc code is supposed to do and I couldn't care less about it. You were claiming thread pools are easy to implement so lets see a nice easy example.
Am 05.07.2026 um 16:41 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
It's not documented but a lot of people have guessed that.
So you don't know.
I'm not the only one wo assumes that; it's not possible otherwise.
Oracle
allows it to limit the absolute CPU-time of a session, a user or
a consumer group. With Windows this isn't possible so you have
to do our own userspace schedulung. With Linux it's possible
since Linux has control groups, but Oracle predates this feature.
Process resource limits have been available in Unix since before
DOS morphed into windows 3.1.
You can set absolute limits with that, but not fractions of the
number of cores. Applying the latter is possible since Linux has
control groups and Windows has no option like that so far.
On Sun, 5 Jul 2026 01:21:56 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 1:19 AM, boltar@caprica.universe wrote:
On Sat, 4 Jul 2026 17:32:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/4/2026 2:16 AM, boltar@caprica.universe wrote:
On Fri, 3 Jul 2026 12:44:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
I'd hate to see your code, must be an overcomplicated mess.
Set your coffee down! Here is my raw test for my mind trying to
sketch out an IOCP server setup from my memory... It should
compile for you, I
Are you seriously expecting me to believe you spent a morning
writing the
1200 lines of code below from memory? Oh please.
Several days on some free time, yes, from memory.
What an exiting life you must have.
Also it looks like win32 code and AFAIK windows for [reasons] can't do >>>>> multiplexing on sockets so you have the ridiculous situation of
needing a
thread per connection whether you like it or not.
Huh? When is the last time you used GetQueuedCompletionStatusEx?
Never even heard of it. Can it also multiplex file descriptors + std
in,out,err
in the same call like select() or poll()? No, didn't think so, so
you'll still
need multiple threads if you want to do all at the same time. Good
old half
assed win32.
Huh? It can work with SOCKETS and FILES.
Well thats nice. What about pipes, fifos and character and block devices?
Of course if they'd use the interface that was standard even when they
were developing win32 it would have been more useful.
So show a short example in 20 lines or less then if its as "simple"
as you
claim.
Huh? My ralloc code or a thread pool?
A thread pool, I have no idea what your ralloc code is supposed to do and I couldn't care less about it. You were claiming thread pools are easy to implement so lets see a nice easy example.
On Fri, 03 Jul 2026 14:41:29 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, so be it. >>>> Just don't be alarmed if you get 10000 threads all of sudden. Or, say a >>>> connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes far more >>> CPU resources than simply adding a new program counter into the scheduler >>> list, right?
You're clearly not an expert on operating systems. There's far
more involved than "simply adding a new program counter to the scheduler list"
during thread creation.
Actually there isn't that much more but if you think otherwise do fill us in on the details.
On 7/5/2026 11:08 AM, Bonita Montero wrote:
Am 05.07.2026 um 16:41 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
It's not documented but a lot of people have guessed that.
So you don't know.
I'm not the only one wo assumes that; it's not possible otherwise.
Oracle
allows it to limit the absolute CPU-time of a session, a user or
a consumer group. With Windows this isn't possible so you have
to do our own userspace schedulung. With Linux it's possible
since Linux has control groups, but Oracle predates this feature.
Process resource limits have been available in Unix since before
DOS morphed into windows 3.1.
You can set absolute limits with that, but not fractions of the
number of cores. Applying the latter is possible since Linux has
control groups and Windows has no option like that so far.
https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups
Kind a, sort a?
Am 05.07.2026 um 16:41 schrieb Scott Lurndal:
Bonita Montero <Bonita.Montero@gmail.com> writes:
It's not documented but a lot of people have guessed that.
So you don't know.
I'm not the only one wo assumes that; it's not possible otherwise.
Oracle
allows it to limit the absolute CPU-time of a session, a user or
a consumer group. With Windows this isn't possible so you have
to do our own userspace schedulung. With Linux it's possible
since Linux has control groups, but Oracle predates this feature.
Process resource limits have been available in Unix since before
DOS morphed into windows 3.1.
You can set absolute limits with that, but not fractions of the
number of cores. Applying the latter is possible since Linux has
control groups and Windows has no option like that so far.
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to do and I >> couldn't care less about it. You were claiming thread pools are easy to
implement so lets see a nice easy example.
A thread pool in 20 lines? You mean to init the sucker and use it as the >user right? Not the guts, its going to take more than that. The logic is >straightforward to me. Yeah, its not that hard because I have made so
many of them in the past.
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to do and I >> couldn't care less about it. You were claiming thread pools are easy to
implement so lets see a nice easy example.
Also... If you think that over 20 lines is complicated, well... You
would be fired on the spot?
On 7/3/2026 8:59 AM, boltar@caprica.universe wrote:
On Fri, 03 Jul 2026 14:41:29 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, so be it. >>>>> Just don't be alarmed if you get 10000 threads all of sudden. Or, say a >>>>> connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a
little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes far more >>>> CPU resources than simply adding a new program counter into the scheduler >>>> list, right?
You're clearly not an expert on operating systems. There's far
more involved than "simply adding a new program counter to the scheduler >list"
during thread creation.
Actually there isn't that much more but if you think otherwise do fill us in >> on the details.
Why don't you fill us in on the details? We already know, but you? Humm....
Am 05.07.2026 um 16:41 schrieb Scott Lurndal:
Process resource limits have been available in Unix since before
DOS morphed into windows 3.1.
You can set absolute limits with that, but not fractions of the
number of cores. Applying the latter is possible since Linux has
control groups and Windows has no option like that so far.
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to
do and I couldn't care less about it. You were claiming thread
pools are easy to implement so lets see a nice easy example.
A thread pool in 20 lines? You mean to init the sucker and use it as
the user right? Not the guts, its going to take more than that. The
logic is straightforward to me. Yeah, its not that hard because I
have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
Bonita Montero <Bonita.Montero@gmail.com> writes:
Am 05.07.2026 um 16:41 schrieb Scott Lurndal:
Process resource limits have been available in Unix since before
DOS morphed into windows 3.1.
You can set absolute limits with that, but not fractions of the
number of cores. Applying the latter is possible since Linux has
control groups and Windows has no option like that so far.
You can limit a process to a set of cores, or an individual core
with taskset and/or numactl. These have been available since the
early 2000's.
Combine that with setrlimit(2) and you have failry
fined grained control of both core assignment and utilization.
On Sun, 5 Jul 2026 13:22:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 8:59 AM, boltar@caprica.universe wrote:
On Fri, 03 Jul 2026 14:41:29 GMTlist"
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, so >>>>>> be it.
Just don't be alarmed if you get 10000 threads all of sudden. Or, >>>>>> say a
connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a >>>>>> little data then just sits there doing nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes
far more
CPU resources than simply adding a new program counter into the
scheduler
list, right?
You're clearly not an expert on operating systems.ÿ There's far
more involved than "simply adding a new program counter to the
scheduler
during thread creation.
Actually there isn't that much more but if you think otherwise do
fill us in
on the details.
Why don't you fill us in on the details? We already know, but you?
Humm....
You made the assertion, you back it up.
On Mon, 6 Jul 2026 09:28:29 -0000 (UTC)
boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to
do and I couldn't care less about it. You were claiming thread
pools are easy to implement so lets see a nice easy example.
A thread pool in 20 lines? You mean to init the sucker and use it as
the user right? Not the guts, its going to take more than that. The
logic is straightforward to me. Yeah, its not that hard because I
have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
On Windows? Yes, exactly as simple as yours:
QueueUserWorkItem(mythreadProc, myThreadContext, WT_EXECUTEDEFAULT);
That is, it is simple for as long as you don't want to join. Otherwise,
it become more involved. But situations in which join is not necessary
are common.
On Sun, 5 Jul 2026 13:16:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to do
and I
couldn't care less about it. You were claiming thread pools are easy
to implement so lets see a nice easy example.
Also... If you think that over 20 lines is complicated, well... You
would be fired on the spot?
You were claiming thread pools are so simple to implement why would anyone not use them. So lets see this simple code of yours, not just some class framework without the details.
On 7/6/2026 11:42 AM, Michael S wrote:
On Mon, 6 Jul 2026 09:28:29 -0000 (UTC)
boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to
do and I couldn't care less about it. You were claiming thread
pools are easy to implement so lets see a nice easy example.
A thread pool in 20 lines? You mean to init the sucker and use it as
the user right? Not the guts, its going to take more than that. The
logic is straightforward to me. Yeah, its not that hard because I
have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
On Windows? Yes, exactly as simple as yours:
ÿÿ QueueUserWorkItem(mythreadProc, myThreadContext, WT_EXECUTEDEFAULT);
That is, it is simple for as long as you don't want to join. Otherwise,
it become more involved. But situations in which join is not necessary
are common.
Using join for a thread pool can be worked out with proper logic.
Detached threads, well, imvvvho, are bad mojo anyway, they have their
place, but I tend to always try to avoid them. Adding threads and
removing them can use join and a read write mutex for the io_workers in
the pool. Adding threads and removing them should be very infrequent
anyway! :^) Usually, we setup a thread pool for say the io_workers that
are one to one with processing units. We can also oversubscribe with creating two threads per. Once that pool is setup, it remains rather
static.
Beware of detached threads unless you know what you are doing!
On Mon, 6 Jul 2026 09:28:29 -0000 (UTC)
boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to
do and I couldn't care less about it. You were claiming thread
pools are easy to implement so lets see a nice easy example.
A thread pool in 20 lines? You mean to init the sucker and use it as
the user right? Not the guts, its going to take more than that. The
logic is straightforward to me. Yeah, its not that hard because I
have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
On Windows? Yes, exactly as simple as yours:
QueueUserWorkItem(mythreadProc, myThreadContext, WT_EXECUTEDEFAULT);
That is, it is simple for as long as you don't want to join. Otherwise,
it become more involved. But situations in which join is not necessary
are common.
On 7/6/2026 2:29 AM, boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:22:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 8:59 AM, boltar@caprica.universe wrote:
On Fri, 03 Jul 2026 14:41:29 GMTlist"
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, so >>>>>>> be it.You do realise setting up and pulling down a TCP connection takes >>>>>> far more
Just don't be alarmed if you get 10000 threads all of sudden. Or, >>>>>>> say a
connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a >>>>>>> little data then just sits there doing nothing for say 20 minutes. >>>>>>
CPU resources than simply adding a new program counter into the
scheduler
list, right?
You're clearly not an expert on operating systems.ÿ There's far
more involved than "simply adding a new program counter to the
scheduler
during thread creation.
Actually there isn't that much more but if you think otherwise do
fill us in
on the details.
Why don't you fill us in on the details? We already know, but you?
Humm....
You made the assertion, you back it up.
Huh? You made the false assertion! You back it up. We already know. Take
a look at:
https://github.com/ZoloZiak/WinNT4
On 7/6/2026 2:29 AM, boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:16:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to do >>>> and I
couldn't care less about it. You were claiming thread pools are easy
to implement so lets see a nice easy example.
Also... If you think that over 20 lines is complicated, well... You
would be fired on the spot?
You were claiming thread pools are so simple to implement why would anyone >> not use them. So lets see this simple code of yours, not just some class
framework without the details.
I am going to make one for my iocp memory experiment. There are many >different ways to engineer them. Then I need to see if I want to use C++ >per_thread data, or use C. Actually, using C for TLS is more to the point.
On Mon, 6 Jul 2026 21:42:17 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Mon, 6 Jul 2026 09:28:29 -0000 (UTC)
boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed
to do and I couldn't care less about it. You were claiming
thread pools are easy to implement so lets see a nice easy
example.
A thread pool in 20 lines? You mean to init the sucker and use it
as the user right? Not the guts, its going to take more than
that. The logic is straightforward to me. Yeah, its not that hard
because I have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
On Windows? Yes, exactly as simple as yours:
QueueUserWorkItem(mythreadProc, myThreadContext,
WT_EXECUTEDEFAULT);
That is, it is simple for as long as you don't want to join.
Otherwise, it become more involved. But situations in which join is
not necessary are common.
Looks like windows maintains its own thread pool for a user which
seems wasteful
but understandable in an OS that seems to require
threads for everything. *nix however does not.
So, i'll ask again for
some example thread pool code.
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 21:42:17 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Mon, 6 Jul 2026 09:28:29 -0000 (UTC)
boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed
to do and I couldn't care less about it. You were claiming
thread pools are easy to implement so lets see a nice easy
example.
A thread pool in 20 lines? You mean to init the sucker and use it
as the user right? Not the guts, its going to take more than
that. The logic is straightforward to me. Yeah, its not that hard
because I have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
On Windows? Yes, exactly as simple as yours:
QueueUserWorkItem(mythreadProc, myThreadContext,
WT_EXECUTEDEFAULT);
That is, it is simple for as long as you don't want to join.
Otherwise, it become more involved. But situations in which join is
not necessary are common.
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
but understandable in an OS that seems to require
threads for everything. *nix however does not.
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
On Windows, at least in theory, only I/O management (i.e. file open,
rename, delete etc...) has to be synchronous. For I/O data operations
(read, write, ioctl) programmer has a choice of whether to do it >synchronously or asynchronously. The only exception I am aware of are >anonymous pipes.
Of course, nowadays file I/O is heavily cached, so even operations
done through asynchronous APIs behave as synchronous most of the time.
But that applies to all OSes.
Michael S <already5chosen@yahoo.com> writes:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 21:42:17 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Mon, 6 Jul 2026 09:28:29 -0000 (UTC)
boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is
supposed to do and I couldn't care less about it. You were
claiming thread pools are easy to implement so lets see a
nice easy example.
A thread pool in 20 lines? You mean to init the sucker and use
it as the user right? Not the guts, its going to take more than
that. The logic is straightforward to me. Yeah, its not that
hard because I have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
On Windows? Yes, exactly as simple as yours:
QueueUserWorkItem(mythreadProc, myThreadContext,
WT_EXECUTEDEFAULT);
That is, it is simple for as long as you don't want to join.
Otherwise, it become more involved. But situations in which join
is not necessary are common.
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
but understandable in an OS that seems to require
threads for everything. *nix however does not.
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
On Windows, at least in theory, only I/O management (i.e. file open, >rename, delete etc...) has to be synchronous. For I/O data operations >(read, write, ioctl) programmer has a choice of whether to do it >synchronously or asynchronously. The only exception I am aware of are >anonymous pipes.
Of course, nowadays file I/O is heavily cached, so even operations
done through asynchronous APIs behave as synchronous most of the
time. But that applies to all OSes.
Does windows have the equivalent of unix raw devices or linux
O_DIRECT, both of which avoid the buffer or file caches in the OS
(and the user level stdio caching)?
On 7/6/2026 12:45 PM, Chris M. Thomasson wrote:
On 7/6/2026 11:42 AM, Michael S wrote:
On Mon, 6 Jul 2026 09:28:29 -0000 (UTC)
boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:01:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to >>>>>> do and I couldn't care less about it. You were claiming thread
pools are easy to implement so lets see a nice easy example.
A thread pool in 20 lines? You mean to init the sucker and use it as >>>>> the user right? Not the guts, its going to take more than that. The
logic is straightforward to me. Yeah, its not that hard because I
have made so many of them in the past.
Oh right, so not quite as simple as:
thread mythread(....)
mythread.detach()
then as you were claiming. Glad we finally cleared that up.
On Windows? Yes, exactly as simple as yours:
ÿÿ QueueUserWorkItem(mythreadProc, myThreadContext, WT_EXECUTEDEFAULT);
That is, it is simple for as long as you don't want to join. Otherwise,
it become more involved. But situations in which join is not necessary
are common.
Using join for a thread pool can be worked out with proper logic.
Detached threads, well, imvvvho, are bad mojo anyway, they have their
place, but I tend to always try to avoid them. Adding threads and
removing them can use join and a read write mutex for the io_workers
in the pool. Adding threads and removing them should be very
infrequent anyway! :^) Usually, we setup a thread pool for say the
io_workers that are one to one with processing units. We can also
oversubscribe with creating two threads per. Once that pool is setup,
it remains rather static.
Beware of detached threads unless you know what you are doing!
Iirc in the past, QueueUserWorkItem etc, was not all that performant wrt custom ones. I think windows has a newer one:
https://learn.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf- threadpoolapiset-createthreadpool
https://learn.microsoft.com/en-us/windows/win32/procthread/using-the- thread-pool-functions
But, I have no problem with making one for myself that only has what it needs.
On Tue, 07 Jul 2026 18:09:31 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Does windows have the equivalent of unix raw devices or linux
O_DIRECT, both of which avoid the buffer or file caches in the OS
(and the user level stdio caching)?
I was never interested in raw devices, so don't know.
Surely, even if support is here it would require admin privilege.
As to O_DIRECT, one can open file with FILE_FLAG_NO_BUFFERING flag.
But when you do it then there are serious restriction on what allowed
and what not.
On Mon, 6 Jul 2026 12:49:24 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/6/2026 2:29 AM, boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:16:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to
do and I
couldn't care less about it. You were claiming thread pools are
easy to implement so lets see a nice easy example.
Also... If you think that over 20 lines is complicated, well... You
would be fired on the spot?
You were claiming thread pools are so simple to implement why would
anyone
not use them. So lets see this simple code of yours, not just some class >>> framework without the details.
I am going to make one for my iocp memory experiment. There are many
different ways to engineer them. Then I need to see if I want to use
C++ per_thread data, or use C. Actually, using C for TLS is more to
the point.
So you don't have any code yet. Got it.
On Mon, 6 Jul 2026 12:49:24 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/6/2026 2:29 AM, boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:16:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:48 AM, boltar@caprica.universe wrote:
A thread pool, I have no idea what your ralloc code is supposed to
do and I
couldn't care less about it. You were claiming thread pools are
easy to implement so lets see a nice easy example.
Also... If you think that over 20 lines is complicated, well... You
would be fired on the spot?
You were claiming thread pools are so simple to implement why would
anyone
not use them. So lets see this simple code of yours, not just some class >>> framework without the details.
I am going to make one for my iocp memory experiment. There are many
different ways to engineer them. Then I need to see if I want to use
C++ per_thread data, or use C. Actually, using C for TLS is more to
the point.
So you don't have any code yet. Got it.
On Mon, 6 Jul 2026 12:31:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/6/2026 2:29 AM, boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:22:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 8:59 AM, boltar@caprica.universe wrote:
On Fri, 03 Jul 2026 14:41:29 GMTlist"
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, >>>>>>>> so be it.You do realise setting up and pulling down a TCP connection takes >>>>>>> far more
Just don't be alarmed if you get 10000 threads all of sudden. >>>>>>>> Or, say a
connection comes in every second for say a half an hour. 1800
connections? Also you need to think about a connection that sends a >>>>>>>> little data then just sits there doing nothing for say 20 minutes. >>>>>>>
CPU resources than
list, right?
You're clearly not an expert on operating systems.ÿ There's far
more involved than "simply adding a new program counter to the
scheduler
during thread creation.
Actually there isn't that much more but if you think otherwise do
fill us in
on the details.
Why don't you fill us in on the details? We already know, but you?
Humm....
You made the assertion, you back it up.
Huh? You made the false assertion! You back it up. We already know.
Take a look at:
https://github.com/ZoloZiak/WinNT4
https://github.com/torvalds/linux
Enjoy.
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
but understandable in an OS that seems to require
threads for everything. *nix however does not.
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 12:49:24 -0700
So you don't have any code yet. Got it.
You are too funny. wow. I think have posted a specialized one for a >lock-free stack test here a couple of months ago. But, trust me. I know
how to make them in many different forms. You think I am going to spend
Oh, well, this is a specialized one I posted for an experimental futex
based lock-free stack:
On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 12:31:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/6/2026 2:29 AM, boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:22:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 8:59 AM, boltar@caprica.universe wrote:
On Fri, 03 Jul 2026 14:41:29 GMTlist"
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Thread per connection model? If that works for your work load, >>>>>>>>> so be it.You do realise setting up and pulling down a TCP connection takes >>>>>>>> far more
Just don't be alarmed if you get 10000 threads all of sudden. >>>>>>>>> Or, say a
connection comes in every second for say a half an hour. 1800 >>>>>>>>> connections? Also you need to think about a connection that sends a >>>>>>>>> little data then just sits there doing nothing for say 20 minutes. >>>>>>>>
CPU resources than
list, right?
You're clearly not an expert on operating systems.ÿ There's far
more involved than "simply adding a new program counter to the
scheduler
during thread creation.
Actually there isn't that much more but if you think otherwise do >>>>>> fill us in
on the details.
Why don't you fill us in on the details? We already know, but you?
Humm....
You made the assertion, you back it up.
Huh? You made the false assertion! You back it up. We already know.
Take a look at:
https://github.com/ZoloZiak/WinNT4
https://github.com/torvalds/linux
Enjoy.
You made an assertion that creating a new thread "is simply adding a new >program counter into the scheduler". I have a feeling that you don't
know what you are talking about. Scott tried to tell you that you are wrong.
That's what Bonita said. ....
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done
by magic pixies?
but understandable in an OS that seems to require
threads for everything. *nix however does not.
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
Wtf are you talking about?
Its quite possible - and I've done it a
number of times - to write a network server in unix with a single
thread & single process using multiplexed sockets via select() or
poll().
Thats how 1990s MUD & chat servers were written and IRC,
Unaxcess along with plenty of other in house company servers.
On Tue, 7 Jul 2026 15:30:29 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 12:31:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/6/2026 2:29 AM, boltar@caprica.universe wrote:
On Sun, 5 Jul 2026 13:22:07 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 8:59 AM, boltar@caprica.universe wrote:
On Fri, 03 Jul 2026 14:41:29 GMTlist"
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled: >>>>>>>>
Thread per connection model? If that works for your work load, >>>>>>>>>> so be it.
Just don't be alarmed if you get 10000 threads all of sudden. >>>>>>>>>> Or, say a
connection comes in every second for say a half an hour. 1800 >>>>>>>>>> connections? Also you need to think about a connection that >>>>>>>>>> sends a
little data then just sits there doing nothing for say 20 >>>>>>>>>> minutes.
You do realise setting up and pulling down a TCP connection >>>>>>>>> takes far more
CPU resources than list, right?
You're clearly not an expert on operating systems.ÿ There's far >>>>>>>> more involved than "simply adding a new program counter to the >>>>>>>> scheduler
during thread creation.
Actually there isn't that much more but if you think otherwise do >>>>>>> fill us in
on the details.
Why don't you fill us in on the details? We already know, but you? >>>>>> Humm....
You made the assertion, you back it up.
Huh? You made the false assertion! You back it up. We already know.
Take a look at:
https://github.com/ZoloZiak/WinNT4
https://github.com/torvalds/linux
Enjoy.
You made an assertion that creating a new thread "is simply adding a
new program counter into the scheduler". I have a feeling that you
don't know what you are talking about. Scott tried to tell you that
you are wrong.
You simply revered to the NT4 code so I simply refered to the linux code. Whats the problem?
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done by
magic pixies?
but understandable in an OS that seems to require
threads for everything. *nix however does not.
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
Wtf are you talking about? Its quite possible - and I've done it a number of times - to write a network server in unix with a single thread & single process
using multiplexed sockets via select() or poll(). Thats how 1990s MUD & chat servers were written and IRC, Unaxcess along with plenty of other in house company servers.
On Wed, 8 Jul 2026 09:34:40 -0000 (UTC)
boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done
by magic pixies?
It costs only if you use it.
Otherwise, accordiing to my understanding, the only cost is few zero-initialized fields in process control block.
but understandable in an OS that seems to require
threads for everything. *nix however does not.
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
Wtf are you talking about?
I am talking about file IO. Was not it obvious?
Its quite possible - and I've done it a
number of times - to write a network server in unix with a single
thread & single process using multiplexed sockets via select() or
poll().
Then either files access in your server was blocking or you used
non-portable extensions to POSIX.
And it's not like on Windows it would be different. Except, may be, if
you want to support very old versions of Windows (>20 y.o.) in
whichcasee you'll only have select() and no poll(). Which is
inconvinience, but relatively minor one.
Thats how 1990s MUD & chat servers were written and IRC,
Unaxcess along with plenty of other in house company servers.
On Tue, 7 Jul 2026 15:17:01 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 12:49:24 -0700
So you don't have any code yet. Got it.
You are too funny. wow. I think have posted a specialized one for a
lock-free stack test here a couple of months ago. But, trust me. I
know how to make them in many different forms. You think I am going to
spend
So you won't have a problem writing some short example code then will you.
Oh, well, this is a specialized one I posted for an experimental futex
based lock-free stack:
I'm jnot wading through 270 lines of code. Demonstrate how "simple" thread pools are to implement or STFU.
Am 06.07.2026 um 20:49 schrieb Michael S:
That's what Bonita said. ....
No, I'm talking about a limit to the amount of consumed CPU time of
a thread in an interval. With Linux that's possible since Linux has
control groups. Windows never had such a capability.
Not sure if a processor group can work with the power management or not.
I think it can.
On Wed, 8 Jul 2026 09:34:40 -0000 (UTC)
boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done
by magic pixies?
It costs only if you use it.
Otherwise, accordiing to my understanding, the only cost is few >zero-initialized fields in process control block.
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
Wtf are you talking about?
I am talking about file IO. Was not it obvious?
Its quite possible - and I've done it a
number of times - to write a network server in unix with a single
thread & single process using multiplexed sockets via select() or
poll().
Then either files access in your server was blocking or you used
non-portable extensions to POSIX.
And it's not like on Windows it would be different. Except, may be, if
you want to support very old versions of Windows (>20 y.o.) in
whichcasee you'll only have select() and no poll(). Which is
inconvinience, but relatively minor one.
On 7/8/2026 2:34 AM, boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done by
magic pixies?
HUH? If you don't create a thread pool in Windows, you are not using
one. There is no cost. Sigh...
On 7/8/2026 2:38 AM, boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 15:17:01 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 12:49:24 -0700
So you don't have any code yet. Got it.
You are too funny. wow. I think have posted a specialized one for a
lock-free stack test here a couple of months ago. But, trust me. I
know how to make them in many different forms. You think I am going to
spend
So you won't have a problem writing some short example code then will you. >>
Oh, well, this is a specialized one I posted for an experimental futex
based lock-free stack:
I'm jnot wading through 270 lines of code. Demonstrate how "simple" thread >> pools are to implement or STFU.
Huh? Make a thread pool is less than 20 lines? Are you daft?
On Wed, 8 Jul 2026 22:16:55 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Wed, 8 Jul 2026 09:34:40 -0000 (UTC)
boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done
by magic pixies?
It costs only if you use it.
Otherwise, accordiing to my understanding, the only cost is few >>zero-initialized fields in process control block.
Whooosh....
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
Wtf are you talking about?
I am talking about file IO. Was not it obvious?
No it wasn't and no you don't need seperate threads to do file I/O , you
can simply multiplex the descriptors in select or poll just like sockets.
Its quite possible - and I've done it a
number of times - to write a network server in unix with a single
thread & single process using multiplexed sockets via select() or
poll().
Then either files access in your server was blocking or you used >>non-portable extensions to POSIX.
Clearly you don't understand how multiplexing works in unix but given file >I/O in userspace is buffered anyway you rarely need to multiplex file I/O >unless its via NFS or similar.
boltar@caprica.universe writes:
No it wasn't and no you don't need seperate threads to do file I/O , you >>can simply multiplex the descriptors in select or poll just like sockets.
Actually, you can't usefully poll regular files. POLLIN and POLLOUT are >always true for
a regular file.
Clearly you don't understand how multiplexing works in unix but given file >>I/O in userspace is buffered anyway you rarely need to multiplex file I/O >>unless its via NFS or similar.
No high performance application will use stdio buffering.
On Wed, 8 Jul 2026 22:16:55 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Wed, 8 Jul 2026 09:34:40 -0000 (UTC)
boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user
which seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done
by magic pixies?
It costs only if you use it.
Otherwise, accordiing to my understanding, the only cost is few >zero-initialized fields in process control block.
Whooosh....
I don't understand what you mean.
IMHO, portable *nix is the one that needs threads (or fork) for
everything.
Wtf are you talking about?
I am talking about file IO. Was not it obvious?
No it wasn't and no you don't need seperate threads to do file I/O ,
you can simply multiplex the descriptors in select or poll just like
sockets.
Its quite possible - and I've done it a
number of times - to write a network server in unix with a single
thread & single process using multiplexed sockets via select() or
poll().
Then either files access in your server was blocking or you used >non-portable extensions to POSIX.
Clearly you don't understand how multiplexing works in unix but given
file I/O in userspace is buffered anyway you rarely need to multiplex
file I/O unless its via NFS or similar.
And it's not like on Windows it would be different. Except, may be,
if you want to support very old versions of Windows (>20 y.o.) in >whichcasee you'll only have select() and no poll(). Which is
inconvinience, but relatively minor one.
select and poll are not an "inconvenience", they're fundamental to how
single threaded servers are implemented on unix. Don't assume just
because the windows versions are a pale shadow of the posix ones
doesn't mean that they're useless.
On Wed, 8 Jul 2026 14:15:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/8/2026 2:34 AM, boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done by
magic pixies?
HUH? If you don't create a thread pool in Windows, you are not using
one. There is no cost. Sigh...
And then the pool is created is just appears by magic, no setup required
on the part of the OS?
On Wed, 8 Jul 2026 14:17:06 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/8/2026 2:38 AM, boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 15:17:01 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:
On Mon, 6 Jul 2026 12:49:24 -0700
So you don't have any code yet. Got it.
You are too funny. wow. I think have posted a specialized one for a
lock-free stack test here a couple of months ago. But, trust me. I
know how to make them in many different forms. You think I am going
to spend
So you won't have a problem writing some short example code then will
you.
Oh, well, this is a specialized one I posted for an experimental
futex based lock-free stack:
I'm jnot wading through 270 lines of code. Demonstrate how "simple"
thread
pools are to implement or STFU.
Huh? Make a thread pool is less than 20 lines? Are you daft?
You were the one claiming how they were so simple to implement. But nice attempt at a back pedal.
Am 08.07.2026 um 23:32 schrieb Chris M. Thomasson:
Not sure if a processor group can work with the power management or
not. I think it can.
OMG, what a nonsense.
Actually, you can't usefully poll regular files. POLLIN and POLLOUT[...]
are always true for a regular file.
aio_read(2), aio_write(2) and lio_listio(2) provide asynchronous
file I/O.
On 7/9/2026 1:34 AM, Bonita Montero wrote:
Am 08.07.2026 um 23:32 schrieb Chris M. Thomasson:
Not sure if a processor group can work with the power management or
not. I think it can.
OMG, what a nonsense.
Not sure what MS means wrt:
https://windowsreport.com/windows-11-hidden-cpu-setting-unlocks- advanced-performance-and-power-controls/
https://learn.microsoft.com/en-us/windows/win32/procthread/cpu-sets
"CPU Sets provide APIs to declare application affinity in a 'soft'
manner that is compatible with OS power management. "
On Sun, 5 Jul 2026 01:22:34 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 1:21 AM, boltar@caprica.universe wrote:
On Sat, 4 Jul 2026 23:36:09 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/3/2026 1:59 AM, boltar@caprica.universe wrote:
On Thu, 2 Jul 2026 11:41:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/2/2026 1:13 AM, boltar@caprica.universe wrote:
They're hard enough to make it a lot of pointless work if its not >>>>>>> necessary. As I said, if you're creating threads every few
milliseconds then
use a thread pool. If you're just creating a thread every few
seconds or longer then a pool is a complete waste of time.
Thread per connection model? If that works for your work load, so >>>>>> be it. Just don't be alarmed if you get 10000 threads all of
sudden. Or, say a connection comes in every second for say a half >>>>>> an hour. 1800 connections? Also you need to think about a
connection that sends a little data then just sits there doing
nothing for say 20 minutes.
You do realise setting up and pulling down a TCP connection takes
far more
CPU resources than simply adding a new program counter into the
scheduler
list, right? If we were talking about creating a new process via
fork() then
your argument might have some merit, but threads? No.
Why destroy the socket? Reuse it:
TF_REUSE_SOCKET
https://learn.microsoft.com/en-us/windows/win32/api/mswsock/nc-
mswsock-lpfn_dis
connectex
I'm not interesting in win32, I only do posix and in posix a socket
is simply
an (indirect) integer index into a kernel network connection. Re-
using one after
the network connection has been closed makes no sense.
Why? TF_REUSE_SOCKET is VERY useful.
Why? Once its down a socket - in unix - is just an integer pointing to nothing.
What difference does it make if the same value gets reused?
3. poll() is more convenient than select(), but functionality-wise
everything that poll can do, select() can do as well.
On 7/9/2026 1:55 AM, boltar@caprica.universe wrote:
On Wed, 8 Jul 2026 14:15:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/8/2026 2:34 AM, boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user which
seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all done by >>>> magic pixies?
HUH? If you don't create a thread pool in Windows, you are not using
one. There is no cost. Sigh...
And then the pool is created is just appears by magic, no setup required
on the part of the OS?
HUH!????? Wtf are you babbling on about, but really. Wow...
We can create a thread pool. Or we can say okay we don't need one. We
don't pay for one if we don't need one.
On 7/9/2026 1:56 AM, boltar@caprica.universe wrote:
You were the one claiming how they were so simple to implement. But nice
attempt at a back pedal.
Oh my. You troll attempt is moronic. Sorry for the harsh lang. I did try
to show you a little thread pool experiment for one of my experimental
futex stacks, but you mocked it? So. Whatever. Its my fault that you do
not know how to implement a simple thread pool. Wrt the one I need to
impl, its method of gaining completions is based in the following
function GetQueuedCompetionStatusEx.
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer pointing to
nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient way. >DisconnectEx. Fairly nice! Avoid calling WSASocket again.
On Thu, 9 Jul 2026 22:15:53 +0300
Michael S <already5chosen@yahoo.com> gabbled:
3. poll() is more convenient than select(), but functionality-wise >everything that poll can do, select() can do as well.
Not entirely true. In select() the max descriptor value is limited to
1 << FD_SETSIZE and the max number of monitored descriptors is
. In poll() these limits don't apply.
On Thu, 9 Jul 2026 12:51:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/9/2026 1:55 AM, boltar@caprica.universe wrote:
On Wed, 8 Jul 2026 14:15:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/8/2026 2:34 AM, boltar@caprica.universe wrote:
On Tue, 7 Jul 2026 20:36:11 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Tue, 7 Jul 2026 10:40:28 -0000 (UTC)
boltar@caprica.universe wrote:
Looks like windows maintains its own thread pool for a user
which seems wasteful
Why wasteful?
If you don't use it, it costs you nothing.
It costs the kernel time and resources or do you think its all
done by magic pixies?
HUH? If you don't create a thread pool in Windows, you are not
using one. There is no cost. Sigh...
And then the pool is created is just appears by magic, no setup
required on the part of the OS?
HUH!????? Wtf are you babbling on about, but really. Wow...
I could ask you the same question.
We can create a thread pool. Or we can say okay we don't need one.
We don't pay for one if we don't need one.
No, but if you do need one there is a cost. I'm not sure why this is confusing you.
On Fri, 10 Jul 2026 09:21:33 -0000 (UTC)
boltar@caprica.universe wrote:
On Thu, 9 Jul 2026 22:15:53 +0300
Michael S <already5chosen@yahoo.com> gabbled:
3. poll() is more convenient than select(), but functionality-wise
everything that poll can do, select() can do as well.
Not entirely true. In select() the max descriptor value is limited to
1 << FD_SETSIZE and the max number of monitored descriptors is
. In poll() these limits don't apply.
Not on Windows.
Windows copied BSD select() API, but implementation under the hood is >different. Actually, now when I started to think about it, >implementation-wise Winsock2 select() is very similar to poll().
For starter, socket in Winsock2 is an integer number, but not *small*
integer number.
fd_set in Winsock2 is array of sockets rather than array of bits.
1. WsaAsyncSelect() associates socket with message queue of particular >window. This mechanism is most applicable to simple single-threaded GUI >applications.
On Fri, 10 Jul 2026 09:22:33 -0000 (UTC)
boltar@caprica.universe wrote:
No, but if you do need one there is a cost. I'm not sure why this is
confusing you.
Of course, I would expect that when you call QueueUserWorkItem() for the >first time, it will cost a little more than CreateThread(). And each
time you call QueueUserWorkItem() when the pool is empty, it again
costs a tiny bit more than CreateThread(). But in the latter case the >difference is most likely undetectable.
On Fri, 10 Jul 2026 14:02:24 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 09:21:33 -0000 (UTC)
boltar@caprica.universe wrote:
On Thu, 9 Jul 2026 22:15:53 +0300
Michael S <already5chosen@yahoo.com> gabbled:
3. poll() is more convenient than select(), but functionality-wise
everything that poll can do, select() can do as well.
Not entirely true. In select() the max descriptor value is limited
to 1 << FD_SETSIZE and the max number of monitored descriptors is
. In poll() these limits don't apply.
Not on Windows.
Windows copied BSD select() API, but implementation under the hood is >different. Actually, now when I started to think about it, >implementation-wise Winsock2 select() is very similar to poll().
For starter, socket in Winsock2 is an integer number, but not *small* >integer number.
fd_set in Winsock2 is array of sockets rather than array of bits.
Then it clearly no longer uses the BSD API because BSD select()
multiplexes integer descriptors, not socket structures, otherwise it
couldn't also multiplex pipes, fifos etc.
1. WsaAsyncSelect() associates socket with message queue of
particular window. This mechanism is most applicable to simple >single-threaded GUI applications.
Huh? Why on earth would a window care about socket data?
Actually, I
don't care, Windows is such a bizarre OS that I'd rather keep my
sanity.
On Fri, 10 Jul 2026 11:22:52 -0000 (UTC)
boltar@caprica.universe wrote:
Huh? Why on earth would a window care about socket data?
Think client, not server.
Actually, I
don't care, Windows is such a bizarre OS that I'd rather keep my
sanity.
That's o.k.
Spouting uninformed statements about something you don't care about like
the one that started this particular sub-thread is less o.k. as far as
I am concerned.
But if you enjoj it then go on.
On Thu, 09 Jul 2026 15:18:38 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
No it wasn't and no you don't need seperate threads to do file I/O , you >>>can simply multiplex the descriptors in select or poll just like sockets.
Actually, you can't usefully poll regular files. POLLIN and POLLOUT are >>always true for
a regular file.
Regular files no, but its very useful when you're talking to something
in /dev.
scott@slp53.sl.home (Scott Lurndal) writes:
[...]
Actually, you can't usefully poll regular files. POLLIN and POLLOUT[...]
are always true for a regular file.
aio_read(2), aio_write(2) and lio_listio(2) provide asynchronous
file I/O.
A small quibble: Those are library functions not system calls,
at least on Linux with glibc. (As I'm sure you know, the "(2)"
suffix denotes section 2 of the manual, which covers system calls.
Section 3 covers library functions.)
On Fri, 10 Jul 2026 14:45:40 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 11:22:52 -0000 (UTC)
boltar@caprica.universe wrote:
Huh? Why on earth would a window care about socket data?
Think client, not server.
I'm thinking window - its a graphical object, just like a bitmap. Why
TF would it care about data of any sort?
Actually, I
don't care, Windows is such a bizarre OS that I'd rather keep my
sanity.
That's o.k.
Spouting uninformed statements about something you don't care about
like the one that started this particular sub-thread is less o.k. as
far as I am concerned.
But if you enjoj it then go on.
I seem to know more about thread pools than some people on here who
make hand waving statements about how "simple" they are then don't
provide any simple code to back that statement up.
boltar@caprica.universe writes:
On Thu, 09 Jul 2026 15:18:38 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
No it wasn't and no you don't need seperate threads to do file I/O , you >>>>can simply multiplex the descriptors in select or poll just like sockets. >>>Actually, you can't usefully poll regular files. POLLIN and POLLOUT are >>>always true for
a regular file.
Regular files no, but its very useful when you're talking to something
in /dev.
Not really. Block devices are always POLLIN and POLLOUT ready.
Some character devices (serial ports for example) may
support the O_NONBLOCK fcntl flag and thus be usable with poll/select.
On Fri, 10 Jul 2026 15:12:08 -0000 (UTC)
boltar@caprica.universe wrote:
I'm thinking window - its a graphical object, just like a bitmap. Why
TF would it care about data of any sort?
I don't know what is meaning of window in your preferred GUI
environment. But on Windows 'window' is not 'graphical' object and not >similar to bitmap. It is a graphical user interface object. The most
prominent feature of window object is "message pump" with its
associated message queue.
Window is commonly visible, but it does not have to be. Invisible
windows that are used purely for sake of they message pump/queue are
not uncommon.
Window-related functions are exported through User32.dll which is
distinct from GDI32.dll responsible for graphics and from Kernel32.dll
which exports basic OS services.
I seem to know more about thread pools than some people on here who
make hand waving statements about how "simple" they are then don't
provide any simple code to back that statement up.
I was talking about part of thread that started when you wrote >"understandable in an OS that seems to require threads for everything".
On Fri, 10 Jul 2026 18:43:37 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 15:12:08 -0000 (UTC)
boltar@caprica.universe wrote:
I'm thinking window - its a graphical object, just like a bitmap.
Why TF would it care about data of any sort?
I don't know what is meaning of window in your preferred GUI
environment. But on Windows 'window' is not 'graphical' object and
not similar to bitmap. It is a graphical user interface object. The
most
In X Windows a window is an area of screen that has a window outline
and returns events. Want to process data? Do it elsewhere, the window
isn't interested.
On Fri, 10 Jul 2026 14:22:28 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 09:22:33 -0000 (UTC)
boltar@caprica.universe wrote:
No, but if you do need one there is a cost. I'm not sure why this is
confusing you.
Of course, I would expect that when you call QueueUserWorkItem() for the
first time, it will cost a little more than CreateThread(). And each
time you call QueueUserWorkItem() when the pool is empty, it again
costs a tiny bit more than CreateThread(). But in the latter case the
difference is most likely undetectable.
A pool is more than just an array of threads or you could simply do
vector<thread> mypool;
and call it a day. Thread pools have to be managed and that can be non trivial.
On Thu, 9 Jul 2026 12:53:39 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/9/2026 1:56 AM, boltar@caprica.universe wrote:
You were the one claiming how they were so simple to implement. But
nice attempt at a back pedal.
Oh my. You troll attempt is moronic. Sorry for the harsh lang. I did
try to show you a little thread pool experiment for one of my
experimental futex stacks, but you mocked it? So. Whatever. Its my
fault that you do
Go look up the definition of mocking. You said implementing a thread
pool is simple then dump almost 300 lines of code as some kind of proof.
I do not call that simple!
not know how to implement a simple thread pool. Wrt the one I need to
impl, its method of gaining completions is based in the following
function GetQueuedCompetionStatusEx.
I'm not interested in some win32 specific function, its irrelevant.
On Fri, 10 Jul 2026 09:21:33 -0000 (UTC)
boltar@caprica.universe wrote:
On Thu, 9 Jul 2026 22:15:53 +0300
Michael S <already5chosen@yahoo.com> gabbled:
3. poll() is more convenient than select(), but functionality-wise
everything that poll can do, select() can do as well.
Not entirely true. In select() the max descriptor value is limited to
1 << FD_SETSIZE and the max number of monitored descriptors is
. In poll() these limits don't apply.
Not on Windows.
Windows copied BSD select() API, but implementation under the hood is different. Actually, now when I started to think about it, implementation-wise Winsock2 select() is very similar to poll().
For starter, socket in Winsock2 is an integer number, but not *small*
integer number.
fd_set in Winsock2 is array of sockets rather than array of bits.
One consequence of it is nfds parameter of select() is DNC.
Max number of descriptors is indeed FD_SETSIZE (by default 64), but
IIRC it can be changed by programmer via simple #define
Also, apart from BSD-compatible select() Winsock2 provides two
additional mechanism of waiting on multiple sockets.
1. WsaAsyncSelect() associates socket with message queue of particular window. This mechanism is most applicable to simple single-threaded GUI applications.
2. WSAEventSelect() associates socket with event object. That is most
generic method that allows permits to combine waiting on socket with
waiting on any other waitable object, most typically by means of WaitForMultipleObjects().
Both methods exist from very begining of Win32/Winsock2 API.
On Fri, 10 Jul 2026 09:21:33 -0000 (UTC)
boltar@caprica.universe wrote:
On Thu, 9 Jul 2026 22:15:53 +0300
Michael S <already5chosen@yahoo.com> gabbled:
3. poll() is more convenient than select(), but functionality-wise
everything that poll can do, select() can do as well.
Not entirely true. In select() the max descriptor value is limited to
1 << FD_SETSIZE and the max number of monitored descriptors is
. In poll() these limits don't apply.
Not on Windows.
Windows copied BSD select() API, but implementation under the hood is different. Actually, now when I started to think about it, implementation-wise Winsock2 select() is very similar to poll().
For starter, socket in Winsock2 is an integer number, but not *small*
integer number.
fd_set in Winsock2 is array of sockets rather than array of bits.
One consequence of it is nfds parameter of select() is DNC.
Max number of descriptors is indeed FD_SETSIZE (by default 64), but
IIRC it can be changed by programmer via simple #define
Also, apart from BSD-compatible select() Winsock2 provides two
additional mechanism of waiting on multiple sockets.
1. WsaAsyncSelect() associates socket with message queue of particular window. This mechanism is most applicable to simple single-threaded GUI applications.
2. WSAEventSelect() associates socket with event object. That is most
generic method that allows permits to combine waiting on socket with
waiting on any other waitable object, most typically by means of WaitForMultipleObjects().
Both methods exist from very begining of Win32/Winsock2 API.
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer pointing
to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient way.
DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to both
with it.
On Fri, 10 Jul 2026 16:06:47 -0000 (UTC)
boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 18:43:37 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 15:12:08 -0000 (UTC)
boltar@caprica.universe wrote:
I'm thinking window - its a graphical object, just like a bitmap.
Why TF would it care about data of any sort?
I don't know what is meaning of window in your preferred GUI
environment. But on Windows 'window' is not 'graphical' object and
not similar to bitmap. It is a graphical user interface object. The
most
In X Windows a window is an area of screen that has a window outline
and returns events. Want to process data? Do it elsewhere, the window
isn't interested.
X is a bad point of comparison - too low level.
Think X-Motif. It is the same era as User32 and likely has similar
concepts. Not that I ever looked.
On 7/10/2026 4:24 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 14:22:28 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 09:22:33 -0000 (UTC)
boltar@caprica.universe wrote:
No, but if you do need one there is a cost. I'm not sure why this is
confusing you.
Of course, I would expect that when you call QueueUserWorkItem() for the >>> first time, it will cost a little more than CreateThread(). And each
time you call QueueUserWorkItem() when the pool is empty, it again
costs a tiny bit more than CreateThread(). But in the latter case the
difference is most likely undetectable.
A pool is more than just an array of threads or you could simply do
vector<thread> mypool;
and call it a day. Thread pools have to be managed and that can be non >trivial.
Sigh. Knowing how to use threads is a first step! Then lets create a
pool. So, you need to know how to use threads first, and yes that
involves know how to sync them.
On 7/10/2026 2:24 AM, boltar@caprica.universe wrote:
On Thu, 9 Jul 2026 12:53:39 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/9/2026 1:56 AM, boltar@caprica.universe wrote:
You were the one claiming how they were so simple to implement. But
nice attempt at a back pedal.
Oh my. You troll attempt is moronic. Sorry for the harsh lang. I did
try to show you a little thread pool experiment for one of my
experimental futex stacks, but you mocked it? So. Whatever. Its my
fault that you do
Go look up the definition of mocking. You said implementing a thread
pool is simple then dump almost 300 lines of code as some kind of proof.
I do not call that simple!
Sigh. You want things so simple as to have a machine to wipe your butt?
Or something? What are you talking about here!
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer pointing
to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient way.
DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to both
with it.
Fair enough. Reusing a socket is nothing new, right?
On Fri, 10 Jul 2026 13:36:52 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:24 AM, boltar@caprica.universe wrote:
On Thu, 9 Jul 2026 12:53:39 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/9/2026 1:56 AM, boltar@caprica.universe wrote:
You were the one claiming how they were so simple to implement. But >>>>> nice attempt at a back pedal.
Oh my. You troll attempt is moronic. Sorry for the harsh lang. I did
try to show you a little thread pool experiment for one of my
experimental futex stacks, but you mocked it? So. Whatever. Its my
fault that you do
Go look up the definition of mocking. You said implementing a thread
pool is simple then dump almost 300 lines of code as some kind of proof. >>> I do not call that simple!
Sigh. You want things so simple as to have a machine to wipe your
butt? Or something? What are you talking about here!
I could ask you the same question. Perhaps your comprehension of english isn't
as good as you think because I thought I was being pretty clear. Anyway, I can't be bothered going around in circles any more, suffice to say thread pools are not simple to implement and never will be.
On Fri, 10 Jul 2026 12:32:18 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 4:24 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 14:22:28 +0300trivial.
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 09:22:33 -0000 (UTC)
boltar@caprica.universe wrote:
No, but if you do need one there is a cost. I'm not sure why this is >>>>> confusing you.
Of course, I would expect that when you call QueueUserWorkItem() for
the
first time, it will cost a little more than CreateThread(). And each
time you call QueueUserWorkItem() when the pool is empty, it again
costs a tiny bit more than CreateThread(). But in the latter case the
difference is most likely undetectable.
A pool is more than just an array of threads or you could simply do
vector<thread> mypool;
and call it a day. Thread pools have to be managed and that can be non
Sigh. Knowing how to use threads is a first step! Then lets create a
pool. So, you need to know how to use threads first, and yes that
involves know how to sync them.
No shit Sherlock, did you get help from Watson with that one? Whats it got
to do with ease of implemtation:?
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer pointing >>>>> to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient
way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to
both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close a socket then
open a new one but its irrelevant.
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer pointing >>>>> to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient
way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to
both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close a socket then
open a new one but its irrelevant.
On Fri, 10 Jul 2026 19:13:06 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 16:06:47 -0000 (UTC)
boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 18:43:37 +0300
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 15:12:08 -0000 (UTC)
boltar@caprica.universe wrote:
I'm thinking window - its a graphical object, just like a bitmap.
Why TF would it care about data of any sort?
I don't know what is meaning of window in your preferred GUI
environment. But on Windows 'window' is not 'graphical' object and
not similar to bitmap. It is a graphical user interface object. The
most
In X Windows a window is an area of screen that has a window outline
and returns events. Want to process data? Do it elsewhere, the window
isn't interested.
X is a bad point of comparison - too low level.
Think X-Motif. It is the same era as User32 and likely has similar
concepts. Not that I ever looked.
All callbacks I've used in GUI libraries on top of X are simply event based for widgets to capture. I've never come across one where on screen objects suddely got promoted to doing their own processing of data and why would
they - the X server is simple a graphics server and doesn't even have to
run on the same machine as the program using it.
Having a window deal with data just seems a moronic paradigm to me - what if more than 1 window needs it or the main core application? Ridiculous.
On 7/11/2026 2:29 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 12:32:18 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 4:24 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 14:22:28 +0300trivial.
Michael S <already5chosen@yahoo.com> gabbled:
On Fri, 10 Jul 2026 09:22:33 -0000 (UTC)
boltar@caprica.universe wrote:
No, but if you do need one there is a cost. I'm not sure why this is >>>>>> confusing you.
Of course, I would expect that when you call QueueUserWorkItem() for >>>>> the
first time, it will cost a little more than CreateThread(). And each >>>>> time you call QueueUserWorkItem() when the pool is empty, it again
costs a tiny bit more than CreateThread(). But in the latter case the >>>>> difference is most likely undetectable.
A pool is more than just an array of threads or you could simply do
vector<thread> mypool;
and call it a day. Thread pools have to be managed and that can be non
Sigh. Knowing how to use threads is a first step! Then lets create a
pool. So, you need to know how to use threads first, and yes that
involves know how to sync them.
No shit Sherlock, did you get help from Watson with that one? Whats it got >> to do with ease of implemtation:?
Ease is relative. Hard for you perhaps?
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer pointing >>>>>> to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient
way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to
both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking
subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close a
socket then
open a new one but its irrelevant.
Reusing a socket make a heck of a lot of sense indeed!
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer pointing >>>>>> to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient
way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to
both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking
subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close a
socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can be >reused for AcceptEx or ConnectEx. No need to call WSASocket to make a
new one.
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me - what if >> more than 1 window needs it or the main core application? Ridiculous.
Create two windows that use the same core app/data?
On Sat, 11 Jul 2026 14:09:51 -0700[...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Ease is relative. Hard for you perhaps?
Yes, its relative to creating a thread then detaching. 2 lines of C++, not much more in C. So, as I keep asking, show us your "simple" pool code.
On Sat, 11 Jul 2026 14:11:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient
way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to
both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking >>> subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close
a socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can
be reused for AcceptEx or ConnectEx. No need to call WSASocket to make
a new one.
Seems WSASocket() returns a structure with a whole load of crap in it
unlike
posix socket() which returns an int. So maybe in win32 it does make sense.
Am 09.07.2026 um 22:01 schrieb Chris M. Thomasson:
On 7/9/2026 1:34 AM, Bonita Montero wrote:
Am 08.07.2026 um 23:32 schrieb Chris M. Thomasson:
Not sure if a processor group can work with the power management or
not. I think it can.
OMG, what a nonsense.
Not sure what MS means wrt:
https://windowsreport.com/windows-11-hidden-cpu-setting-unlocks-
advanced-performance-and-power-controls/
https://learn.microsoft.com/en-us/windows/win32/procthread/cpu-sets
"CPU Sets provide APIs to declare application affinity in a 'soft'
manner that is compatible with OS power management. "
CPU-affinities are a different topic.
On Sat, 11 Jul 2026 14:10:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient
way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to
both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking >>> subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close
a socket then
open a new one but its irrelevant.
Reusing a socket make a heck of a lot of sense indeed!
Maybe in Win32. On *nix its not only pointless, its meaningless. Sockets don't exist in any sense other than being an id for a connection. I suppose
a hacker might like to close a connection in a hacked library , re-open
a new one to their server and present the same socket id to the user application
but I can't think of any other "use".
On Sun, 05 Jul 2026 14:39:45 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 7/5/2026 1:21 AM, boltar@caprica.universe wrote:
I'm not interesting in win32, I only do posix and in posix a socket is >>>> simply
an (indirect) integer index into a kernel network connection. Re-using >>>> one after
the network connection has been closed makes no sense.
Why? TF_REUSE_SOCKET is VERY useful.
Posix has SO_REUSEADDR and SO_REUSEPORT for socket reuse.
Thats not socket re-use, thats allowing a new listen socket to connect to the same interface address and port number before the previous one has been completely torn down.
On Sat, 11 Jul 2026 14:11:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more
efficient way. DisconnectEx. Fairly nice! Avoid calling
WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had
to both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level
networking subsystem. Re-using once the link it was the key for
has been closed makes no sense. You may well get the same integer
value if you close a socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can
be reused for AcceptEx or ConnectEx. No need to call WSASocket to
make a new one.
Seems WSASocket() returns a structure with a whole load of crap in it
unlike posix socket() which returns an int. So maybe in win32 it does
make sense.
On 7/12/2026 8:15 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:09:51 -0700[...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Ease is relative. Hard for you perhaps?
Yes, its relative to creating a thread then detaching. 2 lines of C++, not >> much more in C. So, as I keep asking, show us your "simple" pool code.
I don't work for you. I already showed you a little thread pool using my >experimental lock-free stack, you mocked it. I am working on some other >things right now. Fwiw, check this shit out:
https://skfb.ly/pyP9E
https://skfb.ly/pyXH6
https://skfb.ly/pzTEC
Can your system view these?
On 7/12/2026 8:19 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:11:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient >>>>>>> way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to >>>>>> both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking >>>> subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close
a socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can
be reused for AcceptEx or ConnectEx. No need to call WSASocket to make
a new one.
Seems WSASocket() returns a structure with a whole load of crap in it
unlike
posix socket() which returns an int. So maybe in win32 it does make sense. >>
Well, it creates a socket. Why go through all of that logic when the
socket is in a state that allows for reuse anyway?
On 7/12/2026 8:18 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:10:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient >>>>>>> way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to >>>>>> both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking >>>> subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close
a socket then
open a new one but its irrelevant.
Reusing a socket make a heck of a lot of sense indeed!
Maybe in Win32. On *nix its not only pointless, its meaningless. Sockets
don't exist in any sense other than being an id for a connection. I suppose >> a hacker might like to close a connection in a hacked library , re-open
a new one to their server and present the same socket id to the user
application
but I can't think of any other "use".
I any system. Socket reuse is ideal. Why make a new one?
On Sun, 12 Jul 2026 11:21:52 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:18 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:10:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient >>>>>>>> way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had >>>>>>> to both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level
networking
subsystem. Re-using once the link it was the key for has been
closed makes no sense. You may well get the same integer value if
you close a socket then
open a new one but its irrelevant.
Reusing a socket make a heck of a lot of sense indeed!
Maybe in Win32. On *nix its not only pointless, its meaningless. Sockets >>> don't exist in any sense other than being an id for a connection. I
suppose
a hacker might like to close a connection in a hacked library , re-
open a new one to their server and present the same socket id to the
user application
but I can't think of any other "use".
I any system. Socket reuse is ideal. Why make a new one?
Its just a data structure. At best all you're save is a single memory allocation.
On Sun, 12 Jul 2026 15:19:52 -0000 (UTC)
boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:11:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more
efficient way. DisconnectEx. Fairly nice! Avoid calling
WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had
to both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level
networking subsystem. Re-using once the link it was the key for
has been closed makes no sense. You may well get the same integer
value if you close a socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can
be reused for AcceptEx or ConnectEx. No need to call WSASocket to
make a new one.
Seems WSASocket() returns a structure with a whole load of crap in it
unlike posix socket() which returns an int. So maybe in win32 it does
make sense.
WSASocket() return handle, which is pointer-sized.
Exactly the same as socket() in that regard.
BTW, WSASocket() is a specialised function that is used rather rarely.
I had never seen it used.
Supposedly, it was more useful back when IP networking was less
dominant.
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me -
what if
more than 1 window needs it or the main core application? Ridiculous.
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window" conflicts with another. What a mess.
Just have some graphic objects and a
couple of core threads, one deals with graphics events and callbacks,
the other does everything else. At least thats how graphical
applications are written on sane OS's, not some toy that evolved from a
disk monitor.
On Sun, 12 Jul 2026 10:58:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:15 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:09:51 -0700[...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Ease is relative. Hard for you perhaps?
Yes, its relative to creating a thread then detaching. 2 lines of C+
+, not
much more in C. So, as I keep asking, show us your "simple" pool code.
I don't work for you. I already showed you a little thread pool using
my experimental lock-free stack, you mocked it. I am working on some
other things right now. Fwiw, check this shit out:
I didn't mock it, it simply wasn't an example of thread pool code any more than just giving the source to the linux kernel would be.
https://skfb.ly/pyP9E
https://skfb.ly/pyXH6
https://skfb.ly/pzTEC
Can your system view these?
Once, then cloudfront gave up. Anyway, very impressive but I'm not interested
in webassembly.
On 7/13/2026 3:26 AM, boltar@caprica.universe wrote:
Its just a data structure. At best all you're save is a single memory
allocation.
Its more than just a data structure. WSASocket needs to set it up. Init
it. Saving that is a good thing.
On 7/12/2026 8:23 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me -
what if
more than 1 window needs it or the main core application? Ridiculous.
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window"
conflicts with another. What a mess.
Not sure what you mean. One window can show lets say, real time stats.
The other one can render real time using the GPU. Why should say, FPS be >100% accurate anyway?
Just have some graphic objects and a
couple of core threads, one deals with graphics events and callbacks,
the other does everything else. At least thats how graphical
applications are written on sane OS's, not some toy that evolved from a
disk monitor.
Have you ever used imgui? Its pretty nice.
On Mon, 13 Jul 2026 13:12:32 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:23 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me - >>>>> what if
more than 1 window needs it or the main core application? Ridiculous. >>>>>
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window"
conflicts with another. What a mess.
Not sure what you mean. One window can show lets say, real time stats.
The other one can render real time using the GPU. Why should say, FPS be >>100% accurate anyway?
I'm not going to second guess how people write apps, but I'm sure there are >plenty where 2 or more windows require the same data. Why would you "send" >data to each window instead of just having a central store which is then >picked up by the window draw functions and displayed appropriately.
Just have some graphic objects and a
couple of core threads, one deals with graphics events and callbacks,
the other does everything else. At least thats how graphical
applications are written on sane OS's, not some toy that evolved from a >>> disk monitor.
Have you ever used imgui? Its pretty nice.
Never heard of it. Looks quite nice. Had a poke around the code and all the >cpp files I looked at seemed to be plain C. I can understand using C for >library interfacing but inside the app core it seems a strange choice
unless he's going for max portability, but when why not name the files .c? >Naming them .cpp may confuse some IDEs and even compilers.
boltar@caprica.universe writes:
On Mon, 13 Jul 2026 13:12:32 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:23 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me - >>>>>> what if
more than 1 window needs it or the main core application? Ridiculous. >>>>>>
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window"
conflicts with another. What a mess.
Not sure what you mean. One window can show lets say, real time stats. >>>The other one can render real time using the GPU. Why should say, FPS be >>>100% accurate anyway?
I'm not going to second guess how people write apps, but I'm sure there are >>plenty where 2 or more windows require the same data. Why would you "send" >>data to each window instead of just having a central store which is then >>picked up by the window draw functions and displayed appropriately.
Typical patterns for GUI applications often follow the smalltalk
pattern Model-View-Controller.
On Mon, 13 Jul 2026 13:05:23 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/13/2026 3:26 AM, boltar@caprica.universe wrote:
Its just a data structure. At best all you're save is a single memory
allocation.
Its more than just a data structure. WSASocket needs to set it up.
Init it. Saving that is a good thing.
And it'll need to set it up again for a new connection unless its identical to the previous one which is unlikely but then it would still have to check the values to find out and update them if wrong, hardly efficient.
Hence
all its rarely saving is a malloc() of a blank socket structure, the
cost of which
in the process of setting up a network connection, particularly TCP, is statistical noise.
On 7/14/2026 3:58 AM, boltar@caprica.universe wrote:
On Mon, 13 Jul 2026 13:05:23 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/13/2026 3:26 AM, boltar@caprica.universe wrote:
Its just a data structure. At best all you're save is a single memory >>>> allocation.
Its more than just a data structure. WSASocket needs to set it up.
Init it. Saving that is a good thing.
And it'll need to set it up again for a new connection unless its identical >> to the previous one which is unlikely but then it would still have to check >> the values to find out and update them if wrong, hardly efficient.
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
again. Why not reuse the existing structure brought back into a certian >state such that it can be used with AcceptEx or ConnectEx again and
totally avoid calling WSASocket...
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >than once, on unix a socket is just an id number used to link userspace to
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >>than once, on unix a socket is just an id number used to link userspace to
Specifically, the socket(2) system call returns a standard file descriptor >that can be used with the other file-related system calls such as read, >write, poll/select, ioctl, etc.
On Wed, 15 Jul 2026 14:07:58 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700Specifically, the socket(2) system call returns a standard file descriptor >> that can be used with the other file-related system calls such as read,
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >>> than once, on unix a socket is just an id number used to link userspace to >>
write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets which seems
unnecessarily complicated.
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700Specifically, the socket(2) system call returns a standard file descriptor >>> that can be used with the other file-related system calls such as read,
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >>>> than once, on unix a socket is just an id number used to link userspace to >>>
write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets which >seems
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't be needed in the first place.
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't be needed in the first place.
On Sun, 12 Jul 2026 11:02:53 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:19 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:11:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient >>>>>>>> way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had >>>>>>> to both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level
networking
subsystem. Re-using once the link it was the key for has been
closed makes no sense. You may well get the same integer value if
you close a socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can
be reused for AcceptEx or ConnectEx. No need to call WSASocket to
make a new one.
Seems WSASocket() returns a structure with a whole load of crap in it
unlike
posix socket() which returns an int. So maybe in win32 it does make
sense.
Well, it creates a socket. Why go through all of that logic when the
socket is in a state that allows for reuse anyway?
I guess it depends on how its implemented internally.
It would seem to
me that
the vast majority of the time and effort by the kernel in any OS is setting up and tearing down connections, creating a structure in userspace is probably a fraction of that and plus userspace structures would require field validity checks each time its used whereis with an int its either valid or it isn't.
WSASocket is more fine grain than socket. Also, its needed for
overlapped io on the windozer:
int
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ create_accept(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& listen_sock,ÿÿÿÿÿ // also renamed for consistency
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& accept_sock,ÿÿÿÿÿ // <--- demon slain
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_io& pio
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ) {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket = WSASocket(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ AF_INET, SOCK_STREAM, IPPROTO_TCP,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ nullptr, 0, WSA_FLAG_OVERLAPPED
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (accept_sock.m_raw.m_socket == INVALID_SOCKET)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "create_accept WSASocket() failed: "
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ << WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "accept_socket = " << accept_sock.m_raw.m_socket << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf = accept_sock.m_raw.m_buf;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf_n = accept_sock.m_raw.m_buf_n;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_per_socket = &accept_sock;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_state |= CT_PER_IO_STATE_ACCEPT;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ DWORD bytes_received = 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ BOOL ok = m_winsock.m_wsaex.m_acceptex(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ listen_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &bytes_received,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &pio.m_raw.m_ol
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (!ok && WSAGetLastError() != ERROR_IO_PENDING)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx failed: " << WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx posted!\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
On 7/13/2026 1:08 PM, Chris M. Thomasson wrote:
[...]
WSASocket is more fine grain than socket. Also, its needed for
overlapped io on the windozer:
int
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ create_accept(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& listen_sock,ÿÿÿÿÿ // also renamed for
consistency
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& accept_sock,ÿÿÿÿÿ // <--- demon slain
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_io& pio
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ) {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket = WSASocket(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ AF_INET, SOCK_STREAM, IPPROTO_TCP,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ nullptr, 0, WSA_FLAG_OVERLAPPED
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
This is where I need to prime my per_socket pools with sockets! Instead
of calling WSASocket here, create_accept can check a pool of them first.
If that is empty, then we can create another one and handle the errors
if that fails.
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (accept_sock.m_raw.m_socket == INVALID_SOCKET)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "create_accept WSASocket()
failed: "
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ << WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "accept_socket = " <<
accept_sock.m_raw.m_socket << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf = accept_sock.m_raw.m_buf;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf_n = accept_sock.m_raw.m_buf_n;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_per_socket = &accept_sock;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_state |= CT_PER_IO_STATE_ACCEPT;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ DWORD bytes_received = 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ BOOL ok = m_winsock.m_wsaex.m_acceptex(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ listen_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &bytes_received,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &pio.m_raw.m_ol
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (!ok && WSAGetLastError() != ERROR_IO_PENDING)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx failed: " <<
WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx posted!\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
On 7/16/2026 3:44 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket >>>>>>I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't >> be needed in the first place.
I thought that Linux has a socket reuse thing as well? Anyway...
You should tell MS that. I was lucky enough to be able to talk to some >Windows kernel guys. Iirc, one of them was Neill Clift way back on >comp.programming.threads.
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
On 7/16/2026 3:44 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket >>>>>>I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't >> be needed in the first place.
Why would you closesocket, when we can issue a DisconnectEx and once
that per_io get completed in the io_worker thread pool, we can add the >socket back to the per_socket pool(s), or just issue a new AcceptEx
right there! No need to call closesocket, and then WSASocket again, right?
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
You can limit a process to a set of cores, or an individual core
with taskset and/or numactl. These have been available since the
early 2000's. Combine that with setrlimit(2) and you have failry
fined grained control of both core assignment and utilization.
Am 30.06.2026 um 10:27 schrieb Wuns Haerst:its
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or
ustruntime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m j
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
I found a way to handle that: I've implemented a green thread API and
the scheduler is a generic component which takes a function object as
a template parameter. With that I easily can integrate threads
inlined. For some benchmarks with small threaded tasks this gives a
hughe per- formance advantage. Strike !
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Hopefully after that you measure performance, discover that it's either exactly the same speed as simple code or, more likely, slower and then
you throw complicated crap into trash can, where it belongs.
Well, probably I am hoping for too much.
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
On 7/18/2026 5:15 PM, Chris M. Thomasson wrote:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells
ans whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server,
or a client for that matter. On my free time I am slowly but
surely recreating my old proxy server code from around 2002. So
far mostly from memory. Some of the API's are messing me up a
little. Hard to remember them.
On Linux AIO or io_uring. The fun part is that they have very
similar logic to IOCP.
So you never measure if complicated code is faster than the simple
one or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO
or io_uring is way more efficient than using select, even epoll
iirc.
If you are building a robust server that is meant to scale up, we
need these API's.
Back in the day, 20+ years ago I experimented with all sort of
completion techniques. Worst by far is the thread per connection
crap. It does not scale at all. Actually, WaitForMultipleObjects
worked kind of okay but we must remember to scramble or shift the
objects in the array to avoid starvation. select did not scale,
etc... IOCP on Windows is bar none, the way to go.
On 7/18/2026 5:15 PM, Chris M. Thomasson wrote:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells
ans whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server,
or a client for that matter. On my free time I am slowly but
surely recreating my old proxy server code from around 2002. So
far mostly from memory. Some of the API's are messing me up a
little. Hard to remember them.
On Linux AIO or io_uring. The fun part is that they have very
similar logic to IOCP.
So you never measure if complicated code is faster than the simple
one or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO
or io_uring is way more efficient than using select, even epoll
iirc.
If you are building a robust server that is meant to scale up, we
need these API's.
Back in the day, 20+ years ago I experimented with all sort of
completion techniques. Worst by far is the thread per connection
crap. It does not scale at all. Actually, WaitForMultipleObjects
worked kind of okay but we must remember to scramble or shift the
objects in the array to avoid starvation. select did not scale,
etc... IOCP on Windows is bar none, the way to go.
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or >io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
On Sat, 18 Jul 2026 17:18:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/18/2026 5:15 PM, Chris M. Thomasson wrote:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells
ans whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server,
or a client for that matter. On my free time I am slowly but
surely recreating my old proxy server code from around 2002. So
far mostly from memory. Some of the API's are messing me up a
little. Hard to remember them.
On Linux AIO or io_uring. The fun part is that they have very
similar logic to IOCP.
So you never measure if complicated code is faster than the simple
one or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO
or io_uring is way more efficient than using select, even epoll
iirc.
If you are building a robust server that is meant to scale up, we
need these API's.
Back in the day, 20+ years ago I experimented with all sort of
completion techniques. Worst by far is the thread per connection
crap. It does not scale at all. Actually, WaitForMultipleObjects
worked kind of okay but we must remember to scramble or shift the
objects in the array to avoid starvation. select did not scale,
etc... IOCP on Windows is bar none, the way to go.
What was correct 20+ years ago (would not surprise me if in fact
your measurements were done 25+ years ago) is VERY likely to be wrong
today.
Esp. so for servers that never see a lot of load. Definition of "a
lot" also changed.
On Sat, 18 Jul 2026 17:15:28 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or
io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
I've never used io_uring on linux but just looking at the man page makes
me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the io_uring_sqe structure is a horror story. There are probably easier ways to get high server throughput
than dicking about with this awful API.
On Thu, 16 Jul 2026 12:40:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/16/2026 3:44 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket >>>>>>>I have no idea what "work" windows does with sockets but as I've >>>>>>> said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as >>>>>> read,
write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for
sockets which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it
wouldn't
be needed in the first place.
Why would you closesocket, when we can issue a DisconnectEx and once
that per_io get completed in the io_worker thread pool, we can add the
socket back to the per_socket pool(s), or just issue a new AcceptEx
right there! No need to call closesocket, and then WSASocket again,
right?
No idea, I'm not a win32 developer. Windows seems to make a complete meal
out of what should be - in userspace - a simple process.
On Sat, 18 Jul 2026 17:15:28 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or
io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
I've never used io_uring on linux but just looking at the man page makes
me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the io_uring_sqe structure is a horror story. There are probably easier ways to get high server throughput
than dicking about with this awful API.
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
On 7/19/2026 12:57 AM, boltar@caprica.universe wrote:
I've never used io_uring on linux but just looking at the man page makes
me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the io_uring_sqe
structure is a horror story. There are probably easier ways to get high
server throughput
than dicking about with this awful API.
Btw, if you don't like C... Well, don't use POSIX at all. Stay away from
any linux C API's, etc... ;^)
On Sun, 19 Jul 2026 13:57:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/19/2026 12:57 AM, boltar@caprica.universe wrote:
I've never used io_uring on linux but just looking at the man page makes >>> me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the
io_uring_sqe structure is a horror story. There are probably easier
ways to get high server throughput
than dicking about with this awful API.
Btw, if you don't like C... Well, don't use POSIX at all. Stay away
from any linux C API's, etc... ;^)
I don't have a problem with C but I understand that it gets to a point
where the complexity of something can overwhelm even the best developer
and IMO io_uring has reached that point.
Also its why I use C++ and so don't have to re-write my own hash function
or red black tree container every time I write some code.
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a complete
meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a complete
meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how you >make use of your new socket infrastructure?
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix - and later
posix - socket model is reasonably simple and dovetails nicely with other file descriptor based user subsystems. The only addition I would make is to make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
On 7/21/2026 8:55 AM, boltar@battlestar-galactica.com wrote:
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix - and
later
posix - socket model is reasonably simple and dovetails nicely with other
file descriptor based user subsystems. The only addition I would make is to >> make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
But, you are telling us how it should work, when you don't know how it
does work?
On Tue, 21 Jul 2026 13:47:34 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 8:55 AM, boltar@battlestar-galactica.com wrote:
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix -
and later
posix - socket model is reasonably simple and dovetails nicely with
other
file descriptor based user subsystems. The only addition I would make
is to
make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
But, you are telling us how it should work, when you don't know how it
does work?
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
On Tue, 21 Jul 2026 13:47:34 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 8:55 AM, boltar@battlestar-galactica.com wrote:
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix - and >>> later
posix - socket model is reasonably simple and dovetails nicely with other >>> file descriptor based user subsystems. The only addition I would make is to >>> make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
But, you are telling us how it should work, when you don't know how it >>does work?
I don't care about the kernel implementation, I'm talking about the userspace >side. I'd have thought that was obvious.
On 7/21/2026 2:13 PM, boltar@battlestar-galactica.com wrote:
I don't care about the kernel implementation, I'm talking about the
userspace
side. I'd have thought that was obvious.
But the userspace side wrt sockets needs to work with the kernel side.
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace >>side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our
configurations? Thanks.
On Tue, 21 Jul 2026 14:28:43 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 2:13 PM, boltar@battlestar-galactica.com wrote:
I don't care about the kernel implementation, I'm talking about the
userspace
side. I'd have thought that was obvious.
But the userspace side wrt sockets needs to work with the kernel side.
Are you an LLM? You seem to understand the meaning of words but get lost
on the meaning of the whole post.
On Wed, 22 Jul 2026 01:53:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our
configurations? Thanks.
Why, are you afraid of learning something because it hurts?
On Wed, 22 Jul 2026 01:53:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our
configurations? Thanks.
Why, are you afraid of learning something because it hurts?
boltar@battlestar.co.uk writes:
On Wed, 22 Jul 2026 01:53:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our >>>configurations? Thanks.
Why, are you afraid of learning something because it hurts?
I won't speak for Dan, but since I've decided I don't want to read
what you write (a decision I'm not required or inclined to explain), >deliberately bypassing my filters is extremely rude.
I currently have 4 variants of your posting address in my killfile,
about to be 5. You appear to think that your judgement about whether
I should read your posts is more important than mine. You're wrong.
On 7/22/2026 1:01 AM, boltar@battlestar.co.uk wrote:
On Tue, 21 Jul 2026 14:28:43 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 2:13 PM, boltar@battlestar-galactica.com wrote:
I don't care about the kernel implementation, I'm talking about the
userspace
side. I'd have thought that was obvious.
But the userspace side wrt sockets needs to work with the kernel side.
Are you an LLM? You seem to understand the meaning of words but get lost
on the meaning of the whole post.
No LLM, I have a long history on this group.
You are the one that seems be be missing something... As if you no >experience with using sockets?
boltar@battlestar.co.uk writes:
Why, are you afraid of learning something because it hurts?
I won't speak for Dan, but since I've decided I don't want to read
what you write (a decision I'm not required or inclined to explain), >deliberately bypassing my filters is extremely rude.
I currently have 4 variants of your posting address in my killfile,
about to be 5. You appear to think that your judgement about whether
I should read your posts is more important than mine. You're wrong.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 12 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 04:07:18 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 82,398 |