From Newsgroup: comp.lang.c++

On Tue, 07 Jul 2026 18:09:31 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

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)?

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. https://learn.microsoft.com/en-us/windows/win32/fileio/file-buffering
Again, I never was interested.








--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/6/2026 12:53 PM, Chris M. Thomasson wrote:

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:
-a-a 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.

I need to take a look. I don't know if they work with IOCP in the way I
need. Anyway, I remember a special logic I used for my io_worker threads
that might be incompatible with the "new" windows thread pool. It worked
with per_thread cohorts and was able to fill them up using per_io
completions. If a cohort got too full, it would be processed. Or if a
gqcsex failed to return any per_io's with a zero timeout, they would be processed. akin to:

for (;;)
{
if (! gqcsex(..., 0)) // 0 timeout
{
process_cohort();

gqcxex(..., INFINITE); // wait
}

push_to_cohort(...);

if (cohort.size() > cohort_threshold)
{
process_cohort();
}
}

Each cohort was only able to be seen by its io_worker.


push_to_cohort would just link the completed per_io's to their correct
list using its bitmask flags, example:

struct cohort
{
cohort* m_next;
size_t m_size;

per_io* m_recv;
per_io* m_send;
per_io* m_accept;
per_io* m_connect;
per_io* m_file_read;
per_io* m_file_write;

// etc...
};


So, when a cohort gets processed it just walks itself. The good part is
that it has damn good cache locality. Processing all of the recvs in a
batch is good.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Michael S <already5chosen@yahoo.com> writes:

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.

Makes sense - direct I/O accesses need to be sector-aligned, same
as unix raw devices.

Useful for filesystem maintenance utilities and high-end databases.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:

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.

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
my free time on your difficultly? When I get around to making my iocp
thread pool, I will show you, but you will just mock it out of ignorance
or something. Sigh.

Oh, well, this is a specialized one I posted for an experimental futex
based lock-free stack:



My code:
______________________________________
#include <iostream>
#include <thread>
#include <atomic>
#include <algorithm>
#include <cassert>


#define CT_THREAD_N (42)
#define CT_WORK_N (10000000)
#define CT_WAIT ((ct_node*)0xDEADBEEF)


struct ct_node
{
ct_node* m_next = { nullptr };

ct_node()
{
//std::cout << "(" << this << ")::ct_node::ct_node()\n";
}

~ct_node()
{
//std::cout << "(" << this << ")::ct_node::~ct_node()\n";
}
};


struct ct_stack
{
std::atomic<ct_node*> m_head = { nullptr };

void
push(
ct_node* node
) {
ct_node* head = m_head.load(std::memory_order_relaxed);

do
{
if (head == CT_WAIT)
{
node->m_next = nullptr;
}

else
{
node->m_next = head;
}

} while (! m_head.compare_exchange_weak(
head,
node,
std::memory_order_release)
);

if (head == CT_WAIT)
{
// slow path...
m_head.notify_one();
}
}

ct_node*
flush_wait()
{
ct_node* head = nullptr;

for (;;)
{
head = m_head.exchange(nullptr, std::memory_order_acquire);

while (! head || head == CT_WAIT)
{
// slow path...
head = m_head.exchange(CT_WAIT, std::memory_order_acquire);

if (! head || head == CT_WAIT)
{
m_head.wait(CT_WAIT, std::memory_order_relaxed);
continue;
}
}

break;
}

assert(head && head != CT_WAIT);

return head;
}
};


struct ct_work : public ct_node
{
unsigned long m_state = { 0 };
};


struct ct_shared
{
ct_stack m_stack_in;
ct_stack m_stack_out;

ct_shared()
{
std::cout << "ct_shared::ct_shared()\n" << std::endl;
}

~ct_shared()
{
assert(! m_stack_in.m_head || m_stack_in.m_head == CT_WAIT);
assert(! m_stack_out.m_head || m_stack_out.m_head == CT_WAIT);

std::cout << "ct_shared::~ct_shared()\n" << std::endl;
}
};


void
ct_thread(
ct_shared& shared
) {
unsigned long state = 0;

while (! state)
{
ct_work* head = (ct_work*)shared.m_stack_in.flush_wait();

while (head)
{
ct_work* next = (ct_work*)head->m_next;

if (head->m_state == 666)
{
// Shutdown detected...
state = 1;
shared.m_stack_in.push(head);
}

else
{
shared.m_stack_out.push(head);
}

head = next;
}
}

//std::cout << "shutdown..." << std::endl;
}


int
main()
{
{
std::cout << "Futex Stack Test\n";
std::cout << "by: Chris M. Thomasson\n";
std::cout << "version: (0.0.1)\n";
std::cout << "_________________________________\n" << std::endl;
}

unsigned long g_ct_work_alloations = 0;
unsigned long g_ct_work_dealloations = 0;

{
std::cout << "CT_THREAD_N = " << CT_THREAD_N << std::endl;
std::cout << "CT_WORK_N = " << CT_WORK_N << std::endl;
std::cout << "CT_WAIT = " << CT_WAIT << std::endl;
}

{
ct_shared shared = { };

std::thread threads[CT_THREAD_N];

std::cout << "\nLaunching threads...\n" << std::endl;

for (unsigned long i = 0; i < CT_THREAD_N; ++i)
{
threads[i] = std::thread(ct_thread, std::ref(shared));
}

//std::this_thread::sleep_for(std::chrono::seconds(2));

std::cout << "\nGenerate work...\n" << std::endl;

// Generate work...
{
for (unsigned long i = 0; i < CT_WORK_N; ++i)
{
shared.m_stack_in.push(new ct_work);
++g_ct_work_alloations;
}
}

// Wait for work...
{
unsigned long wn = 0;

while (wn < CT_WORK_N)
{
ct_work* head = (ct_work*)shared.m_stack_out.flush_wait();

while (head)
{
ct_work* next = (ct_work*)head->m_next;
delete head;
++g_ct_work_dealloations;
++wn;
head = next;
}
}
}

std::cout << "\nCompleted all work!\n" << std::endl;
std::cout << "Sending shutdown state...\n" << std::endl;

// Send shutdown state...
{
for (unsigned long i = 0; i < CT_THREAD_N; ++i)
{
ct_work* w = new ct_work;
++g_ct_work_alloations;
w->m_state = 666;
shared.m_stack_in.push(w);
}
}

// Join threads...
{
for (unsigned long i = 0; i < CT_THREAD_N; ++i)
{
threads[i].join();
}
}

std::cout << "\nThreads joined...\n" << std::endl;

// Dump shutdown state...
std::cout << "Dump shutdown state...\n" << std::endl;

{
ct_work* head = (ct_work*)shared.m_stack_in.m_head.load(std::memory_order_relaxed);
shared.m_stack_in.m_head = nullptr;

while (head)
{
ct_work* next = (ct_work*)head->m_next;
delete head;
++g_ct_work_dealloations;
head = next;
}
}

std::cout << "\nShutdown complete!\n" << std::endl;
}

// Sanity check...
{
std::cout << "g_ct_work_alloations = " << g_ct_work_alloations
<< "\n";
std::cout << "g_ct_work_dealloations = " <<
g_ct_work_dealloations << std::endl;

if (g_ct_work_alloations != g_ct_work_dealloations)
{
std::cout << "Pardon my French, but shit!!!!!!!!!!!!!! NOT GOOD\n" << std::endl;
std::cout << "DAMN IT!!!! Grrrrr\n" << std::endl;
}
}

std::cout << "\nFin!\n" << std::endl;

return 0;
}
______________________________________



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/7/2026 3:41 AM, boltar@caprica.universe wrote:

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.

Take a look at an older post of mine from 2025:

Futex Stack Test...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 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
list, right?

You're clearly not an expert on operating systems.-a 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....

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. --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 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
list, right?

You're clearly not an expert on operating systems.-a 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....

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?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/8/2026 2:38 AM, boltar@caprica.universe wrote:

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 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 list, right?

You're clearly not an expert on operating systems.-a 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....

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?

Well, its a lot more than just, like you said: "simply adding a new
program counter to the scheduler list"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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...

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/8/2026 12:16 PM, Michael S wrote:

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.

Winnt 4.0 had IOCP that works with sockets and files.

Thats how 1990s MUD & chat servers were written and IRC,
Unaxcess along with plenty of other in house company servers.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/8/2026 6:47 AM, Bonita Montero wrote:

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

boltar@caprica.universe writes:

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.

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.

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.

No high performance application will use stdio buffering.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

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.

Obviously not. They'd use memory mapping, open the disk device directly
or use some OS specific interface.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Thu, 9 Jul 2026 08:55:22 -0000 (UTC)
boltar@caprica.universe wrote:

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.

Your reading comprehension is so poor... :(
So I'd speak sloooow.

1. WinNt had select() from the very beginning (1993).
Which is not surprising, considering that its original IP
implementation was based on BSD.

2. WinNt did not have pool()) until 2006.
Which is not surprising, considering that it's original IP
implementation was based on BSD.

3. poll() is more convenient than select(), but functionality-wise
everything that poll can do, select() can do as well.

Do you understand now, or it was still too fast?












--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/9/2026 1:56 AM, boltar@caprica.universe wrote:

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.

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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. "
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:

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?

TF_REUSE_SOCKET allows one to reuse a socket in a more efficient way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 FD_SETSIZE.
In poll() these limits don't apply.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Fri, 10 Jul 2026 09:22:33 -0000 (UTC)
boltar@caprica.universe wrote:

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.

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.
That's how pools work.
If you don't expect that cases when pool is not empty on request are
most common then don't use thread pool.

The point of QueueUserWorkItem() is not doing some magic that the user
can not on his own, but saving him programming time and bugs.







--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Fri, 10 Jul 2026 11:22:52 -0000 (UTC)
boltar@caprica.universe wrote:

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?

Think client, not server.
For example, telnet client in hyperterminal.
[O.T.]
Hyperterminal was rather buggy. Despite that I encountered many people
that liked it so much that they went to trouble of installing it on
Win7 and may be even later.
[/O.T.]

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.








--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

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.)

They are implemented as system calls on SVR4/Unixware, SVR4/MK
and IIRC Solaris.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Fri, 10 Jul 2026 15:12:08 -0000 (UTC)
boltar@caprica.universe wrote:

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?

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.

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.

I was talking about part of thread that started when you wrote
"understandable in an OS that seems to require threads for everything".

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Fri, 10 Jul 2026 15:32:45 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:

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.

I've done multiplexing on character devices, select() works just fine. Not
sure why you're wibbling about the NONBLOCK flag, its irrelevant in this situation.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

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 knew MSWin was wierd but its design just sounds fucking bizarre, like something dreamt up by someone on LSD. Why TF would you want an on
screen object to do processing? What else, does a sound get sent data too
in Windows?

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".

Perhaps be clearer then.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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!

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/10/2026 4:02 AM, Michael S wrote:

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.

GetQueuedCompletionStausEx is the one "modern" way to wait on SOCKET's, FILE's, etc...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/10/2026 4:02 AM, Michael S wrote:

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.

Beware of WaitForMultipleObjects. You need to move the handles around or
else starvation can occur!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 +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.

No shit Sherlock, did you get help from Watson with that one? Whats it got
to do with ease of implemtation:?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/11/2026 2:30 AM, boltar@caprica.universe wrote:

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.

Knowing what you are doing is the main battle.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 +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.

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:

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.

Create two windows that use the same core app/data?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Sat, 11 Jul 2026 14:09:51 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:

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 +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.

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?

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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".

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/9/2026 8:58 PM, Bonita Montero wrote:

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.

I can be the only way Windows can have power management wrt not wanting
a certain cpu set to get hot. Or a gpu set... Heck the TDS! Iirc, the
timeout on windows that can terminate a compute shader before its done computing!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/5/2026 8:50 AM, boltar@caprica.universe wrote:

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.

Socket reuse. Easy, let use it again for an AcceptEx, or a ConnectEx. Or closesocket and let it die.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.









--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/13/2026 3:26 AM, boltar@caprica.universe wrote:

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.

Its more than just a data structure. WSASocket needs to set it up. Init
it. Saving that is a good thing.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/12/2026 1:05 PM, Michael S wrote:

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.

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;
}
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/13/2026 2:39 AM, boltar@caprica.universe wrote:

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.

Oh. I meant my models. Btw, afaict the site uses WebGL.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

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.

The .cpp and .h files I looked at were actual C++ (using namespaces).

Although one wonders why the author felt it necessary
to disable all the useful compiler warnings for GCC and clang
in demo.cpp.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 14 Jul 2026 14:31:52 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:

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.

Fair enough. Smalltalk certainly had many qualities, but efficiency wasn't
one of them.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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...

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.

No. Its more than that.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:

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

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
the kernel network subsystem. Once the network connection is closed or put into
TIME_WAIT all you're left with is a useless integer hence re-use is irrelevant and in fact there's every chance it'll be re-issued for another socket, pipe, file whatever very soon.

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...

Sounds like a lot of userspace nonsense that is specific to win32.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 -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 seems
unnecessarily complicated.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 -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 seems
unnecessarily complicated.

Avoiding another call to WSASocket is beneficial.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 GMT
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 >seems
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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 GMT
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

seems

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!

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 GMT
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

seems

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/13/2026 2:42 AM, boltar@caprica.universe wrote:

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.

Indeed it does. Its a kernel call, and does some things. Avoid calling closesocket and then socket again!

Also, think of what can occur. Say we want a graceful shutdown. shutdown(SD_SEND), wait for a zero byte recv, or whatever. If we can
reuse that socket for an accept or connect, well, GOOD! Why would I call closesocket on it when I don't have to. Actually, reusing sockets is
part of POSIX with some flags. Perhaps not as fine grain as Windows, but whatever.

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.

Its more than that. It works with the kernel as well.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a create_accept(
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a per_socket& listen_sock,-a-a-a-a-a // also renamed for
consistency
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a per_socket& accept_sock,-a-a-a-a-a // <--- demon slain
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a per_io& pio
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a ) {
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a accept_sock.m_raw.m_socket = WSASocket(
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a AF_INET, SOCK_STREAM, IPPROTO_TCP,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a nullptr, 0, WSA_FLAG_OVERLAPPED
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a );

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.

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a if (accept_sock.m_raw.m_socket == INVALID_SOCKET)
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a {
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "create_accept WSASocket() failed: "
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a << WSAGetLastError() << "\n";
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a return 1;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "accept_socket = " << accept_sock.m_raw.m_socket << "\n";

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_buf = accept_sock.m_raw.m_buf;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_buf_n = accept_sock.m_raw.m_buf_n;

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_per_socket = &accept_sock;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_state |= CT_PER_IO_STATE_ACCEPT;

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a DWORD bytes_received = 0;

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a BOOL ok = m_winsock.m_wsaex.m_acceptex(
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a listen_sock.m_raw.m_socket,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a accept_sock.m_raw.m_socket,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_buf,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 0,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a sizeof(SOCKADDR_IN) + 16,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a sizeof(SOCKADDR_IN) + 16,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a &bytes_received,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a &pio.m_raw.m_ol
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a );

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a if (!ok && WSAGetLastError() != ERROR_IO_PENDING)
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a {
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "AcceptEx failed: " <<
WSAGetLastError() << "\n";
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a return 1;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "AcceptEx posted!\n";
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a return 0;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a }

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/16/2026 1:56 PM, Chris M. Thomasson wrote:

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
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a create_accept(
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a per_socket& listen_sock,-a-a-a-a-a // also renamed for
consistency
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a per_socket& accept_sock,-a-a-a-a-a // <--- demon slain
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a per_io& pio
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a ) {
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a accept_sock.m_raw.m_socket = WSASocket(
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a AF_INET, SOCK_STREAM, IPPROTO_TCP,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a nullptr, 0, WSA_FLAG_OVERLAPPED
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a );

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.

Well, that should be before create_accept anyway. accept_sock should
already have a working accept_sock.m_raw.m_socket

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a if (accept_sock.m_raw.m_socket == INVALID_SOCKET)
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a {
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "create_accept WSASocket()
failed: "
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a << WSAGetLastError() << "\n";
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a return 1;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "accept_socket = " << >> accept_sock.m_raw.m_socket << "\n";

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_buf = accept_sock.m_raw.m_buf;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_buf_n = accept_sock.m_raw.m_buf_n;

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_per_socket = &accept_sock;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_state |= CT_PER_IO_STATE_ACCEPT;

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a DWORD bytes_received = 0;

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a BOOL ok = m_winsock.m_wsaex.m_acceptex(
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a listen_sock.m_raw.m_socket, >> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a accept_sock.m_raw.m_socket, >> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a pio.m_raw.m_buf,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 0,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a sizeof(SOCKADDR_IN) + 16, >> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a sizeof(SOCKADDR_IN) + 16, >> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a &bytes_received,
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a &pio.m_raw.m_ol
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a );

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a if (!ok && WSAGetLastError() != ERROR_IO_PENDING)
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a {
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "AcceptEx failed: " <<
WSAGetLastError() << "\n";
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a return 1;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a std::cout << "AcceptEx posted!\n"; >> -a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a return 0;
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a }

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Thu, 16 Jul 2026 12:37:20 -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 GMT
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

seems

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...

I've already explained that SO_REUSEADDR simply allows a new listen socket to listen on an interface+port combination while the previous listen socket is still in TIME_WAIT. It has nothing to do with re-using a socket.

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!

Which has nothing to do with re-using sockets.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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 GMT
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

seems

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Am 30.06.2026 um 10:27 schrieb Wuns Haerst:

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 rCo or its
runtime rCo 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. IrCOm 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 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 !
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

Am 06.07.2026 um 19:47 schrieb Scott Lurndal:

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.

With setrlimit() it's not possible what I've mentioned. Or show me
how to reduce the CPU-time consumed by a thread or a thread group
over a time interval. That's only possible with control groups on
current Linuxes.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On Fri, 17 Jul 2026 13:45:09 +0200
Wuns Haerst <Wuns.Haerst@wurstfabrik.at> wrote:

Am 30.06.2026 um 10:27 schrieb Wuns Haerst:

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 rCo or its runtime rCo 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. IrCOm 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 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 !

If it helps, it's a sure sign that the job would be better done
non-threaded. Did you consider state machine?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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!

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.

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

Fwiw, https://www.devdigest.org/articles/epoll-vs-io-uring-why-linux-async-io-changed-forever
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.







--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/18/2026 7:00 PM, Michael S wrote:

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.

A lot of load back then was around 50 to 60 thousand concurrent
connections all loaded with activity, some random disconnects, graceful shutdowns, connect then artificially wait trying to blow the server up,
need timeout detection here, anyway... Thread per connections were crap
wrt scalability! BIG TIME! IOCP on Windows, the only way.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/19/2026 12:57 AM, boltar@caprica.universe wrote:

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.

Make your own. Heck... io_uring is more low level than IOCP!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:

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 GMT
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

seems

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.

Make your own OS and show them how its done. ;^)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/19/2026 12:57 AM, boltar@caprica.universe wrote:

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.

Btw, if you don't like C... Well, don't use POSIX at all. Stay away from
any linux C API's, etc... ;^)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/20/2026 12:51 AM, boltar@battlestar-galactica.com wrote:

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.

io_uring vs aio is way different at hyper low level. Almost akin to the difference between dx11 vs dx12, or Vulkan.

Use it when you want to get scalable servers.

Afaict, IOCP is the best windows has at the moment...

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.

Fair enough. C++ can handle low level as good as C can. Notice my atomic_region and my ralloc region allocator I posted in this thread?
They can be used with io_uring. mmap, does not matter.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

On 7/21/2026 2:13 PM, boltar@battlestar-galactica.com wrote:

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.

But the userspace side wrt sockets needs to work with the kernel side.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c++

In article <113ond3$2ncgf$1@dont-email.me>,
<boltar@battlestar-galactica.com> wrote:

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.

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.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2