On 7/12/2026 8:18 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:10:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient >>>>>>> way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had to >>>>>> both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level networking >>>> subsystem. Re-using once the link it was the key for has been closed
makes no sense. You may well get the same integer value if you close
a socket then
open a new one but its irrelevant.
Reusing a socket make a heck of a lot of sense indeed!
Maybe in Win32. On *nix its not only pointless, its meaningless. Sockets
don't exist in any sense other than being an id for a connection. I suppose >> a hacker might like to close a connection in a hacked library , re-open
a new one to their server and present the same socket id to the user
application
but I can't think of any other "use".
I any system. Socket reuse is ideal. Why make a new one?
On Sun, 12 Jul 2026 11:21:52 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:18 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:10:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient >>>>>>>> way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had >>>>>>> to both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level
networking
subsystem. Re-using once the link it was the key for has been
closed makes no sense. You may well get the same integer value if
you close a socket then
open a new one but its irrelevant.
Reusing a socket make a heck of a lot of sense indeed!
Maybe in Win32. On *nix its not only pointless, its meaningless. Sockets >>> don't exist in any sense other than being an id for a connection. I
suppose
a hacker might like to close a connection in a hacked library , re-
open a new one to their server and present the same socket id to the
user application
but I can't think of any other "use".
I any system. Socket reuse is ideal. Why make a new one?
Its just a data structure. At best all you're save is a single memory allocation.
On Sun, 12 Jul 2026 15:19:52 -0000 (UTC)
boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:11:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more
efficient way. DisconnectEx. Fairly nice! Avoid calling
WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had
to both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level
networking subsystem. Re-using once the link it was the key for
has been closed makes no sense. You may well get the same integer
value if you close a socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can
be reused for AcceptEx or ConnectEx. No need to call WSASocket to
make a new one.
Seems WSASocket() returns a structure with a whole load of crap in it
unlike posix socket() which returns an int. So maybe in win32 it does
make sense.
WSASocket() return handle, which is pointer-sized.
Exactly the same as socket() in that regard.
BTW, WSASocket() is a specialised function that is used rather rarely.
I had never seen it used.
Supposedly, it was more useful back when IP networking was less
dominant.
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me -
what if
more than 1 window needs it or the main core application? Ridiculous.
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window" conflicts with another. What a mess.
Just have some graphic objects and a
couple of core threads, one deals with graphics events and callbacks,
the other does everything else. At least thats how graphical
applications are written on sane OS's, not some toy that evolved from a
disk monitor.
On Sun, 12 Jul 2026 10:58:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:15 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:09:51 -0700[...]
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Ease is relative. Hard for you perhaps?
Yes, its relative to creating a thread then detaching. 2 lines of C+
+, not
much more in C. So, as I keep asking, show us your "simple" pool code.
I don't work for you. I already showed you a little thread pool using
my experimental lock-free stack, you mocked it. I am working on some
other things right now. Fwiw, check this shit out:
I didn't mock it, it simply wasn't an example of thread pool code any more than just giving the source to the linux kernel would be.
https://skfb.ly/pyP9E
https://skfb.ly/pyXH6
https://skfb.ly/pzTEC
Can your system view these?
Once, then cloudfront gave up. Anyway, very impressive but I'm not interested
in webassembly.
On 7/13/2026 3:26 AM, boltar@caprica.universe wrote:
Its just a data structure. At best all you're save is a single memory
allocation.
Its more than just a data structure. WSASocket needs to set it up. Init
it. Saving that is a good thing.
On 7/12/2026 8:23 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me -
what if
more than 1 window needs it or the main core application? Ridiculous.
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window"
conflicts with another. What a mess.
Not sure what you mean. One window can show lets say, real time stats.
The other one can render real time using the GPU. Why should say, FPS be >100% accurate anyway?
Just have some graphic objects and a
couple of core threads, one deals with graphics events and callbacks,
the other does everything else. At least thats how graphical
applications are written on sane OS's, not some toy that evolved from a
disk monitor.
Have you ever used imgui? Its pretty nice.
On Mon, 13 Jul 2026 13:12:32 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:23 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me - >>>>> what if
more than 1 window needs it or the main core application? Ridiculous. >>>>>
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window"
conflicts with another. What a mess.
Not sure what you mean. One window can show lets say, real time stats.
The other one can render real time using the GPU. Why should say, FPS be >>100% accurate anyway?
I'm not going to second guess how people write apps, but I'm sure there are >plenty where 2 or more windows require the same data. Why would you "send" >data to each window instead of just having a central store which is then >picked up by the window draw functions and displayed appropriately.
Just have some graphic objects and a
couple of core threads, one deals with graphics events and callbacks,
the other does everything else. At least thats how graphical
applications are written on sane OS's, not some toy that evolved from a >>> disk monitor.
Have you ever used imgui? Its pretty nice.
Never heard of it. Looks quite nice. Had a poke around the code and all the >cpp files I looked at seemed to be plain C. I can understand using C for >library interfacing but inside the app core it seems a strange choice
unless he's going for max portability, but when why not name the files .c? >Naming them .cpp may confuse some IDEs and even compilers.
boltar@caprica.universe writes:
On Mon, 13 Jul 2026 13:12:32 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:23 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:41:04 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:28 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 19:13:06 +0300
Having a window deal with data just seems a moronic paradigm to me - >>>>>> what if
more than 1 window needs it or the main core application? Ridiculous. >>>>>>
Create two windows that use the same core app/data?
I meant who gets the data first and what if the logic in one "window"
conflicts with another. What a mess.
Not sure what you mean. One window can show lets say, real time stats. >>>The other one can render real time using the GPU. Why should say, FPS be >>>100% accurate anyway?
I'm not going to second guess how people write apps, but I'm sure there are >>plenty where 2 or more windows require the same data. Why would you "send" >>data to each window instead of just having a central store which is then >>picked up by the window draw functions and displayed appropriately.
Typical patterns for GUI applications often follow the smalltalk
pattern Model-View-Controller.
On Mon, 13 Jul 2026 13:05:23 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/13/2026 3:26 AM, boltar@caprica.universe wrote:
Its just a data structure. At best all you're save is a single memory
allocation.
Its more than just a data structure. WSASocket needs to set it up.
Init it. Saving that is a good thing.
And it'll need to set it up again for a new connection unless its identical to the previous one which is unlikely but then it would still have to check the values to find out and update them if wrong, hardly efficient.
Hence
all its rarely saving is a malloc() of a blank socket structure, the
cost of which
in the process of setting up a network connection, particularly TCP, is statistical noise.
On 7/14/2026 3:58 AM, boltar@caprica.universe wrote:
On Mon, 13 Jul 2026 13:05:23 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/13/2026 3:26 AM, boltar@caprica.universe wrote:
Its just a data structure. At best all you're save is a single memory >>>> allocation.
Its more than just a data structure. WSASocket needs to set it up.
Init it. Saving that is a good thing.
And it'll need to set it up again for a new connection unless its identical >> to the previous one which is unlikely but then it would still have to check >> the values to find out and update them if wrong, hardly efficient.
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
again. Why not reuse the existing structure brought back into a certian >state such that it can be used with AcceptEx or ConnectEx again and
totally avoid calling WSASocket...
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >than once, on unix a socket is just an id number used to link userspace to
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >>than once, on unix a socket is just an id number used to link userspace to
Specifically, the socket(2) system call returns a standard file descriptor >that can be used with the other file-related system calls such as read, >write, poll/select, ioctl, etc.
On Wed, 15 Jul 2026 14:07:58 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700Specifically, the socket(2) system call returns a standard file descriptor >> that can be used with the other file-related system calls such as read,
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >>> than once, on unix a socket is just an id number used to link userspace to >>
write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets which seems
unnecessarily complicated.
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700Specifically, the socket(2) system call returns a standard file descriptor >>> that can be used with the other file-related system calls such as read,
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've said more >>>> than once, on unix a socket is just an id number used to link userspace to >>>
write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets which >seems
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't be needed in the first place.
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket
I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't be needed in the first place.
On Sun, 12 Jul 2026 11:02:53 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/12/2026 8:19 AM, boltar@caprica.universe wrote:
On Sat, 11 Jul 2026 14:11:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/11/2026 2:32 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 15:36:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/10/2026 2:25 AM, boltar@caprica.universe wrote:
On Fri, 10 Jul 2026 00:16:41 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/5/2026 8:49 AM, boltar@caprica.universe wrote:
Why? Once its down a socket - in unix - is just an integer
pointing to nothing.
What difference does it make if the same value gets reused?
TF_REUSE_SOCKET allows one to reuse a socket in a more efficient >>>>>>>> way. DisconnectEx. Fairly nice! Avoid calling WSASocket again.
Sounds like win32 is a whole other world. Thank god I never had >>>>>>> to both with it.
Fair enough. Reusing a socket is nothing new, right?
On *nix a socket is simply a integer key into the lower level
networking
subsystem. Re-using once the link it was the key for has been
closed makes no sense. You may well get the same integer value if
you close a socket then
open a new one but its irrelevant.
After a DisconnctEx returns successfully, the socket in question can
be reused for AcceptEx or ConnectEx. No need to call WSASocket to
make a new one.
Seems WSASocket() returns a structure with a whole load of crap in it
unlike
posix socket() which returns an int. So maybe in win32 it does make
sense.
Well, it creates a socket. Why go through all of that logic when the
socket is in a state that allows for reuse anyway?
I guess it depends on how its implemented internally.
It would seem to
me that
the vast majority of the time and effort by the kernel in any OS is setting up and tearing down connections, creating a structure in userspace is probably a fraction of that and plus userspace structures would require field validity checks each time its used whereis with an int its either valid or it isn't.
WSASocket is more fine grain than socket. Also, its needed for
overlapped io on the windozer:
int
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ create_accept(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& listen_sock,ÿÿÿÿÿ // also renamed for consistency
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& accept_sock,ÿÿÿÿÿ // <--- demon slain
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_io& pio
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ) {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket = WSASocket(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ AF_INET, SOCK_STREAM, IPPROTO_TCP,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ nullptr, 0, WSA_FLAG_OVERLAPPED
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (accept_sock.m_raw.m_socket == INVALID_SOCKET)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "create_accept WSASocket() failed: "
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ << WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "accept_socket = " << accept_sock.m_raw.m_socket << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf = accept_sock.m_raw.m_buf;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf_n = accept_sock.m_raw.m_buf_n;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_per_socket = &accept_sock;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_state |= CT_PER_IO_STATE_ACCEPT;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ DWORD bytes_received = 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ BOOL ok = m_winsock.m_wsaex.m_acceptex(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ listen_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &bytes_received,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &pio.m_raw.m_ol
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (!ok && WSAGetLastError() != ERROR_IO_PENDING)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx failed: " << WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx posted!\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
On 7/13/2026 1:08 PM, Chris M. Thomasson wrote:
[...]
WSASocket is more fine grain than socket. Also, its needed for
overlapped io on the windozer:
int
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ create_accept(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& listen_sock,ÿÿÿÿÿ // also renamed for
consistency
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_socket& accept_sock,ÿÿÿÿÿ // <--- demon slain
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ per_io& pio
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ ) {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket = WSASocket(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ AF_INET, SOCK_STREAM, IPPROTO_TCP,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ nullptr, 0, WSA_FLAG_OVERLAPPED
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
This is where I need to prime my per_socket pools with sockets! Instead
of calling WSASocket here, create_accept can check a pool of them first.
If that is empty, then we can create another one and handle the errors
if that fails.
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (accept_sock.m_raw.m_socket == INVALID_SOCKET)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "create_accept WSASocket()
failed: "
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ << WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "accept_socket = " <<
accept_sock.m_raw.m_socket << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf = accept_sock.m_raw.m_buf;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf_n = accept_sock.m_raw.m_buf_n;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_per_socket = &accept_sock;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_state |= CT_PER_IO_STATE_ACCEPT;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ DWORD bytes_received = 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ BOOL ok = m_winsock.m_wsaex.m_acceptex(
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ listen_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ accept_sock.m_raw.m_socket,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ pio.m_raw.m_buf,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 0,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ sizeof(SOCKADDR_IN) + 16,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &bytes_received,
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ &pio.m_raw.m_ol
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ );
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ if (!ok && WSAGetLastError() != ERROR_IO_PENDING)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx failed: " <<
WSAGetLastError() << "\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 1;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ std::cout << "AcceptEx posted!\n";
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return 0;
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ }
On 7/16/2026 3:44 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket >>>>>>I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't >> be needed in the first place.
I thought that Linux has a socket reuse thing as well? Anyway...
You should tell MS that. I was lucky enough to be able to talk to some >Windows kernel guys. Iirc, one of them was Neill Clift way back on >comp.programming.threads.
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
On 7/16/2026 3:44 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket >>>>>>I have no idea what "work" windows does with sockets but as I've
said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as read, >>>>> write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for sockets
which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it wouldn't >> be needed in the first place.
Why would you closesocket, when we can issue a DisconnectEx and once
that per_io get completed in the io_worker thread pool, we can add the >socket back to the per_socket pool(s), or just issue a new AcceptEx
right there! No need to call closesocket, and then WSASocket again, right?
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or its
runtime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m just
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
You can limit a process to a set of cores, or an individual core
with taskset and/or numactl. These have been available since the
early 2000's. Combine that with setrlimit(2) and you have failry
fined grained control of both core assignment and utilization.
Am 30.06.2026 um 10:27 schrieb Wuns Haerst:its
I measured the time it takes to create a thread on both Windows and
Linux. On Windows, it takes around 120,000 clock cycles, whereas on
Linux, it takes about a third of that.
It occurred to me that one could simply inline the thread's main
function. This would eliminate the need for the operating system
call to create the thread. In this scenario, the compiler ? or
ustruntime ? would have to handle the scheduling.
I estimate that this would reduce the thread creation overhead to
just a few clock cycles, making thread pools unnecessary. I?m j
not sure yet exactly how to go about implementing this. Perhaps
someone here can help me with it.
Please send any relevant suggestions via email only, as I intend
to patent this idea once it is fully developed.
I found a way to handle that: I've implemented a green thread API and
the scheduler is a generic component which takes a function object as
a template parameter. With that I easily can integrate threads
inlined. For some benchmarks with small threaded tasks this gives a
hughe per- formance advantage. Strike !
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Hopefully after that you measure performance, discover that it's either exactly the same speed as simple code or, more likely, slower and then
you throw complicated crap into trash can, where it belongs.
Well, probably I am hoping for too much.
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells ans
whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server, or
a client for that matter. On my free time I am slowly but surely
recreating my old proxy server code from around 2002. So far mostly
from memory. Some of the API's are messing me up a little. Hard to
remember them.
On Linux AIO or io_uring. The fun part is that they have very similar
logic to IOCP.
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
On 7/18/2026 5:15 PM, Chris M. Thomasson wrote:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells
ans whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server,
or a client for that matter. On my free time I am slowly but
surely recreating my old proxy server code from around 2002. So
far mostly from memory. Some of the API's are messing me up a
little. Hard to remember them.
On Linux AIO or io_uring. The fun part is that they have very
similar logic to IOCP.
So you never measure if complicated code is faster than the simple
one or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO
or io_uring is way more efficient than using select, even epoll
iirc.
If you are building a robust server that is meant to scale up, we
need these API's.
Back in the day, 20+ years ago I experimented with all sort of
completion techniques. Worst by far is the thread per connection
crap. It does not scale at all. Actually, WaitForMultipleObjects
worked kind of okay but we must remember to scramble or shift the
objects in the array to avoid starvation. select did not scale,
etc... IOCP on Windows is bar none, the way to go.
On 7/18/2026 5:15 PM, Chris M. Thomasson wrote:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells
ans whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server,
or a client for that matter. On my free time I am slowly but
surely recreating my old proxy server code from around 2002. So
far mostly from memory. Some of the API's are messing me up a
little. Hard to remember them.
On Linux AIO or io_uring. The fun part is that they have very
similar logic to IOCP.
So you never measure if complicated code is faster than the simple
one or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO
or io_uring is way more efficient than using select, even epoll
iirc.
If you are building a robust server that is meant to scale up, we
need these API's.
Back in the day, 20+ years ago I experimented with all sort of
completion techniques. Worst by far is the thread per connection
crap. It does not scale at all. Actually, WaitForMultipleObjects
worked kind of okay but we must remember to scramble or shift the
objects in the array to avoid starvation. select did not scale,
etc... IOCP on Windows is bar none, the way to go.
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or >io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
On Sat, 18 Jul 2026 17:18:48 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/18/2026 5:15 PM, Chris M. Thomasson wrote:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 3:32 AM, Michael S wrote:
On Thu, 16 Jul 2026 12:37:20 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
If I am on Windows I use IOCP and use all of it, all the bells
ans whistles. If I am on Linux, I would use io_uring for SURE!
Well, when in Rome? IOCP on Windows is the way to write a server,
or a client for that matter. On my free time I am slowly but
surely recreating my old proxy server code from around 2002. So
far mostly from memory. Some of the API's are messing me up a
little. Hard to remember them.
On Linux AIO or io_uring. The fun part is that they have very
similar logic to IOCP.
So you never measure if complicated code is faster than the simple
one or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO
or io_uring is way more efficient than using select, even epoll
iirc.
If you are building a robust server that is meant to scale up, we
need these API's.
Back in the day, 20+ years ago I experimented with all sort of
completion techniques. Worst by far is the thread per connection
crap. It does not scale at all. Actually, WaitForMultipleObjects
worked kind of okay but we must remember to scramble or shift the
objects in the array to avoid starvation. select did not scale,
etc... IOCP on Windows is bar none, the way to go.
What was correct 20+ years ago (would not surprise me if in fact
your measurements were done 25+ years ago) is VERY likely to be wrong
today.
Esp. so for servers that never see a lot of load. Definition of "a
lot" also changed.
On Sat, 18 Jul 2026 17:15:28 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or
io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
I've never used io_uring on linux but just looking at the man page makes
me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the io_uring_sqe structure is a horror story. There are probably easier ways to get high server throughput
than dicking about with this awful API.
On Thu, 16 Jul 2026 12:40:42 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/16/2026 3:44 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 15:51:10 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/15/2026 8:54 AM, boltar@caprica.universe wrote:
On Wed, 15 Jul 2026 14:07:58 GMTseems
scott@slp53.sl.home (Scott Lurndal) gabbled:
boltar@caprica.universe writes:
On Tue, 14 Jul 2026 13:45:36 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
Huh? It saves a lot of work wrt closesocket, and calling WSASocket >>>>>>>I have no idea what "work" windows does with sockets but as I've >>>>>>> said more
than once, on unix a socket is just an id number used to link
userspace to
Specifically, the socket(2) system call returns a standard file
descriptor
that can be used with the other file-related system calls such as >>>>>> read,
write, poll/select, ioctl, etc.
Indeed. Windows OTOH appears to have a specific C struct for
sockets which
unnecessarily complicated.
Avoiding another call to WSASocket is beneficial.
If windows didn't have a userspace struct representing a socket it
wouldn't
be needed in the first place.
Why would you closesocket, when we can issue a DisconnectEx and once
that per_io get completed in the io_worker thread pool, we can add the
socket back to the per_socket pool(s), or just issue a new AcceptEx
right there! No need to call closesocket, and then WSASocket again,
right?
No idea, I'm not a win32 developer. Windows seems to make a complete meal
out of what should be - in userspace - a simple process.
On Sat, 18 Jul 2026 17:15:28 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:
On 7/18/2026 1:12 PM, Michael S wrote:
On Fri, 17 Jul 2026 12:00:55 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
So you never measure if complicated code is faster than the simple one
or not.
Somehow, it's what I expected.
Why do you assume that? IOCP is WAY more efficient than using say,
select, or the event based thing using WaitForMultipleObjects. AIO or
io_uring is way more efficient than using select, even epoll iirc.
If you are building a robust server that is meant to scale up, we need
these API's.
I've never used io_uring on linux but just looking at the man page makes
me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the io_uring_sqe structure is a horror story. There are probably easier ways to get high server throughput
than dicking about with this awful API.
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
On 7/19/2026 12:57 AM, boltar@caprica.universe wrote:
I've never used io_uring on linux but just looking at the man page makes
me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the io_uring_sqe
structure is a horror story. There are probably easier ways to get high
server throughput
than dicking about with this awful API.
Btw, if you don't like C... Well, don't use POSIX at all. Stay away from
any linux C API's, etc... ;^)
On Sun, 19 Jul 2026 13:57:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/19/2026 12:57 AM, boltar@caprica.universe wrote:
I've never used io_uring on linux but just looking at the man page makes >>> me want to run for the hills. Setup and retrieval looks highly
complicated with C pointers all over the place. Frankly the
io_uring_sqe structure is a horror story. There are probably easier
ways to get high server throughput
than dicking about with this awful API.
Btw, if you don't like C... Well, don't use POSIX at all. Stay away
from any linux C API's, etc... ;^)
I don't have a problem with C but I understand that it gets to a point
where the complexity of something can overwhelm even the best developer
and IMO io_uring has reached that point.
Also its why I use C++ and so don't have to re-write my own hash function
or red black tree container every time I write some code.
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a complete
meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a complete
meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how you >make use of your new socket infrastructure?
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix - and later
posix - socket model is reasonably simple and dovetails nicely with other file descriptor based user subsystems. The only addition I would make is to make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
On 7/21/2026 8:55 AM, boltar@battlestar-galactica.com wrote:
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix - and
later
posix - socket model is reasonably simple and dovetails nicely with other
file descriptor based user subsystems. The only addition I would make is to >> make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
But, you are telling us how it should work, when you don't know how it
does work?
On Tue, 21 Jul 2026 13:47:34 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 8:55 AM, boltar@battlestar-galactica.com wrote:
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix -
and later
posix - socket model is reasonably simple and dovetails nicely with
other
file descriptor based user subsystems. The only addition I would make
is to
make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
But, you are telling us how it should work, when you don't know how it
does work?
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
On Tue, 21 Jul 2026 13:47:34 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 8:55 AM, boltar@battlestar-galactica.com wrote:
On Mon, 20 Jul 2026 13:16:54 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/20/2026 12:49 AM, boltar@battlestar-galactica.com wrote:
On Sun, 19 Jul 2026 13:55:37 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/17/2026 2:27 AM, boltar@caprica.universe wrote:
No idea, I'm not a win32 developer. Windows seems to make a
complete meal
out of what should be - in userspace - a simple process.
Make your own OS and show them how its done. ;^)
I dont need to - thomson and Richie did it in 1969.
Well, patch the linux kernel, or the winnt kernel, and show them how
you make use of your new socket infrastructure?
I don't follow. All I'm saying is while its not perfect, the unix - and >>> later
posix - socket model is reasonably simple and dovetails nicely with other >>> file descriptor based user subsystems. The only addition I would make is to >>> make AF_INET sockets visible in the filesystem just like AF_UNIX ones.
But, you are telling us how it should work, when you don't know how it >>does work?
I don't care about the kernel implementation, I'm talking about the userspace >side. I'd have thought that was obvious.
On 7/21/2026 2:13 PM, boltar@battlestar-galactica.com wrote:
I don't care about the kernel implementation, I'm talking about the
userspace
side. I'd have thought that was obvious.
But the userspace side wrt sockets needs to work with the kernel side.
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace >>side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our
configurations? Thanks.
On Tue, 21 Jul 2026 14:28:43 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 2:13 PM, boltar@battlestar-galactica.com wrote:
I don't care about the kernel implementation, I'm talking about the
userspace
side. I'd have thought that was obvious.
But the userspace side wrt sockets needs to work with the kernel side.
Are you an LLM? You seem to understand the meaning of words but get lost
on the meaning of the whole post.
On Wed, 22 Jul 2026 01:53:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our
configurations? Thanks.
Why, are you afraid of learning something because it hurts?
On Wed, 22 Jul 2026 01:53:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our
configurations? Thanks.
Why, are you afraid of learning something because it hurts?
boltar@battlestar.co.uk writes:
On Wed, 22 Jul 2026 01:53:29 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <113ond3$2ncgf$1@dont-email.me>,
I don't care about the kernel implementation, I'm talking about the userspace
side. I'd have thought that was obvious.
Would you mind not changing your `From:` header, so that those
of us who have plonked you don't have to keep updating our >>>configurations? Thanks.
Why, are you afraid of learning something because it hurts?
I won't speak for Dan, but since I've decided I don't want to read
what you write (a decision I'm not required or inclined to explain), >deliberately bypassing my filters is extremely rude.
I currently have 4 variants of your posting address in my killfile,
about to be 5. You appear to think that your judgement about whether
I should read your posts is more important than mine. You're wrong.
On 7/22/2026 1:01 AM, boltar@battlestar.co.uk wrote:
On Tue, 21 Jul 2026 14:28:43 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 7/21/2026 2:13 PM, boltar@battlestar-galactica.com wrote:
I don't care about the kernel implementation, I'm talking about the
userspace
side. I'd have thought that was obvious.
But the userspace side wrt sockets needs to work with the kernel side.
Are you an LLM? You seem to understand the meaning of words but get lost
on the meaning of the whole post.
No LLM, I have a long history on this group.
You are the one that seems be be missing something... As if you no >experience with using sockets?
boltar@battlestar.co.uk writes:
Why, are you afraid of learning something because it hurts?
I won't speak for Dan, but since I've decided I don't want to read
what you write (a decision I'm not required or inclined to explain), >deliberately bypassing my filters is extremely rude.
I currently have 4 variants of your posting address in my killfile,
about to be 5. You appear to think that your judgement about whether
I should read your posts is more important than mine. You're wrong.
[thread pools are]
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.
Am 30.06.2026 um 16:14 schrieb Scott Lurndal:
Don't bother.ÿÿ It's been done, more than once.ÿ See, for example,
Unixware 2.0.ÿÿ It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Fiber-like context-switchs are *much* faster than through the kernel.
The problem with that is you don't have any context switchs among
your "threads" when you run kernel-code.
Oracle does user-level scheduling and solves the kernel-issue by
never calling any blocking kernel-calls.
On Tue, 30 Jun 2026 17:05:50 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
Wuns Haerst <Wuns.Haerst@wurstfabrik.at> writes:
Am 30.06.2026 um 17:39 schrieb boltar@caprica.universe:
On Tue, 30 Jun 2026 14:14:47 GMT
Don't bother. It's been done, more than once. See, for example,
Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Java of course being a prime example with its green threads.
According to Wikipedia Java had green threads between 1997 and 2000.
Only on linux. Java on SunOS/Solaris/Unixware used Unix[*] threads.
IIRC threads on linux up until kernel 3 were actually seperate processes with a behind the scenes userspace hack to share process data. No idea why threads weren't built into the kernel from the start, perhaps too complicated or Linus
didn't see the point of them.
On 01/07/2026 09:22, boltar@caprica.universe wrote:
On Tue, 30 Jun 2026 17:05:50 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
Wuns Haerst <Wuns.Haerst@wurstfabrik.at> writes:
Am 30.06.2026 um 17:39 schrieb boltar@caprica.universe:
On Tue, 30 Jun 2026 14:14:47 GMT
Don't bother. It's been done, more than once. See, for example, >>>>>> Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Java of course being a prime example with its green threads.
According to Wikipedia Java had green threads between 1997 and 2000.
Only on linux. Java on SunOS/Solaris/Unixware used Unix[*] threads.
IIRC threads on linux up until kernel 3 were actually seperate processes with
a behind the scenes userspace hack to share process data. No idea why threads
weren't built into the kernel from the start, perhaps too complicated or Linus
didn't see the point of them.
Because the start is "int main() {}", you must type at least one
character /after/ that to implement threads, necessarily they will not
be present at the start.
On Tue, 30 Jun 2026 17:05:50 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
Wuns Haerst <Wuns.Haerst@wurstfabrik.at> writes:
Am 30.06.2026 um 17:39 schrieb boltar@caprica.universe:
On Tue, 30 Jun 2026 14:14:47 GMT
Don't bother. It's been done, more than once. See, for example, >>>>>> Unixware 2.0. It turns out that userspace thread scheduling
does not perform as well as kernel-based thread scheduling.
Java of course being a prime example with its green threads.
According to Wikipedia Java had green threads between 1997 and 2000.
Only on linux. Java on SunOS/Solaris/Unixware used Unix[*] threads.
IIRC threads on linux up until kernel 3 were actually seperate processes with
a behind the scenes userspace hack to share process data. No idea why threads
weren't built into the kernel from the start, perhaps too complicated or >Linus
didn't see the point of them.
Because the start is "int main() {}", you must type at least one
character /after/ that to implement threads, necessarily they will not
be present at the start.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 8 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 189:23:07 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 84,212 |