On Sat, 13 Feb 2021 12:52:50 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/13/2021 2:38 AM, mickspud@potatofield.co.uk wrote:
On Fri, 12 Feb 2021 13:08:32 -0800something
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/12/2021 8:20 AM, mickspud@potatofield.co.uk wrote:
if you've only programmed on a toy OS like Windows that can even do
as fundamental as multiplexing network sockets without threading then I >> guess
you may well be screwed without them.
Are you familiar with IOCP?
Nope, but having skim read about it I don't see anything there that multi >>> process couldn't accomplish. If you know otherwise then feel free to explain.
IOCP is basically windows version of POSIX aio. Just make sure to never
create a process and/or thread per connection. That really, really bad.
I guess that depends on how long many connections you're expecting per unit time, how long they stay up and how important the server is. I wrote a middleware system that forked every time a new connection came but but we only
expected a few connections a minute and they'd stay up for 2-3 mins at a time.
Plus it was a critical system and if the main process went down the company backend would grind to a halt so multiplexing and threading were off the table.
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're expecting per unit >> time, how long they stay up and how important the server is. I wrote a
middleware system that forked every time a new connection came but but we >only
expected a few connections a minute and they'd stay up for 2-3 mins at a >time.
Plus it was a critical system and if the main process went down the company >> backend would grind to a halt so multiplexing and threading were off the >table.
I have seen cases where the server created a thread-per-connection and
all was well... Until more and more users started using it!
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're expecting per unit >>> time, how long they stay up and how important the server is. I wrote atime.
middleware system that forked every time a new connection came but but we >> only
expected a few connections a minute and they'd stay up for 2-3 mins at a
Plus it was a critical system and if the main process went down the company >>> backend would grind to a halt so multiplexing and threading were off thetable.
I have seen cases where the server created a thread-per-connection and
all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes
it brings down the entire system. Thats really not something you want if its mission critical.
On 2/23/2021 1:18 AM, mickspud@potatofield.co.uk wrote:[...]
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
Your are 100% correct that a single thread going down should NOT off the system/server. Your are right. Multiple processes needed.
On 2/23/2021 1:18 AM, mickspud@potatofield.co.uk wrote:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
I have seen cases where the server created a thread-per-connection and
all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes >> it brings down the entire system. Thats really not something you want if its >> mission critical.
Your are correct... Therefore one should have multiple processes, and >multiple threads within each process. Thank you for making me remember >various setups I have coded:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're expecting per unit >>> time, how long they stay up and how important the server is. I wrote a
middleware system that forked every time a new connection came but but we >>only
expected a few connections a minute and they'd stay up for 2-3 mins at a >>time.
Plus it was a critical system and if the main process went down the company >>> backend would grind to a halt so multiplexing and threading were off the >>table.
I have seen cases where the server created a thread-per-connection and
all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes
it brings down the entire system. Thats really not something you want if its >mission critical.
mickspud@potatofield.co.uk writes:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're expecting per unit
time, how long they stay up and how important the server is. I wrote a >>>> middleware system that forked every time a new connection came but but we >>>only
expected a few connections a minute and they'd stay up for 2-3 mins at a >>>time.
Plus it was a critical system and if the main process went down the company
backend would grind to a halt so multiplexing and threading were off the >>>table.
I have seen cases where the server created a thread-per-connection and >>>all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes >>it brings down the entire system. Thats really not something you want if its >>mission critical.
Your premise is faulty.
On Tue, 23 Feb 2021 14:59:04 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
mickspud@potatofield.co.uk writes:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're expecting per unit
time, how long they stay up and how important the server is. I wrote a >>>>> middleware system that forked every time a new connection came but but we >>>>only
expected a few connections a minute and they'd stay up for 2-3 mins at a >>>>time.
Plus it was a critical system and if the main process went down the company
backend would grind to a halt so multiplexing and threading were off the >>>>table.
I have seen cases where the server created a thread-per-connection and >>>>all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes >>>it brings down the entire system. Thats really not something you want if its >>>mission critical.
Your premise is faulty.
No, it isn't.
mickspud@potatofield.co.uk writes:
On Tue, 23 Feb 2021 14:59:04 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
mickspud@potatofield.co.uk writes:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're expecting per >unit
time, how long they stay up and how important the server is. I wrote a >>>>>> middleware system that forked every time a new connection came but but we
only
expected a few connections a minute and they'd stay up for 2-3 mins at a >>>>>time.
Plus it was a critical system and if the main process went down the >company
backend would grind to a halt so multiplexing and threading were off the >>>>>table.
I have seen cases where the server created a thread-per-connection and >>>>>all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes >>>>it brings down the entire system. Thats really not something you want if its
mission critical.
Your premise is faulty.
No, it isn't.
Any modern operating system is multithreaded. They recover just fine
when "1 thread crashes". Ipso facto.
On Tue, 23 Feb 2021 16:20:27 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Your premise is faulty.
No, it isn't.
Any modern operating system is multithreaded. They recover just fine
when "1 thread crashes". Ipso facto.
If you're talking about the OS kernel, no, they don't always recover just fine >if something goes wrong. Its called a Kernel panic or blue screen in Windows.
However the OS controls what happens with itself, user processes have limited >control over what the OS does to them when they page fault or similar.
mickspud@potatofield.co.uk writes:
On Tue, 23 Feb 2021 14:59:04 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
mickspud@potatofield.co.uk writes:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're expecting per unit
time, how long they stay up and how important the server is. I wrote a >>>>>> middleware system that forked every time a new connection came but but weonly
expected a few connections a minute and they'd stay up for 2-3 mins at a >>>>> time.
Plus it was a critical system and if the main process went down the company
backend would grind to a halt so multiplexing and threading were off the >>>>> table.
I have seen cases where the server created a thread-per-connection and >>>>> all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes >>>> it brings down the entire system. Thats really not something you want if its
mission critical.
Your premise is faulty.
No, it isn't.
Any modern operating system is multithreaded. They recover just fine
when "1 thread crashes". Ipso facto.
On 2/23/2021 8:20 AM, Scott Lurndal wrote:
mickspud@potatofield.co.uk writes:
On Tue, 23 Feb 2021 14:59:04 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
mickspud@potatofield.co.uk writes:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/15/2021 1:34 AM, mickspud@potatofield.co.uk wrote:
I guess that depends on how long many connections you're
expecting per unit
time, how long they stay up and how important the server is. Ionly
wrote a
middleware system that forked every time a new connection came
but but we
expected a few connections a minute and they'd stay up for 2-3time.
mins at a
Plus it was a critical system and if the main process went down >>>>>>> the company
backend would grind to a halt so multiplexing and threading were >>>>>>> off thetable.
I have seen cases where the server created a thread-per-connection >>>>>> and
all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread
crashes
it brings down the entire system. Thats really not something you
want if its
mission critical.
Your premise is faulty.
No, it isn't.
Any modern operating system is multithreaded. They recover just fine
when "1 thread crashes". Ipso facto.
In user space, when a thread in a process crashes, it brings the whole process down.
On Tue, 23 Feb 2021 01:26:22 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
On 2/23/2021 1:18 AM, mickspud@potatofield.co.uk wrote:
On Mon, 22 Feb 2021 21:08:43 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
I have seen cases where the server created a thread-per-connection and >>>> all was well... Until more and more users started using it!
The big achilles heal of multithreaded systems is that if 1 thread crashes >>> it brings down the entire system. Thats really not something you want if its
mission critical.
Your are correct... Therefore one should have multiple processes, and
multiple threads within each process. Thank you for making me remember
various setups I have coded:
Yes, thats certainly an approach I've seen a lot. Of course marshalling both processes and threads can be a difficult task and programmers who are well versed in both multithreaded and multiprocess development are not as common as
they should be.
mickspud@potatofield.co.uk writes:
On Tue, 23 Feb 2021 16:20:27 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Your premise is faulty.
No, it isn't.
Any modern operating system is multithreaded. They recover just fine >>>when "1 thread crashes". Ipso facto.
If you're talking about the OS kernel, no, they don't always recover just fine
if something goes wrong. Its called a Kernel panic or blue screen in Windows.
Windows is hardly an exemplar of operating system design. I've been
writing operating systems for four decades, and I stand by my assertion.
However the OS controls what happens with itself, user processes have limited >>control over what the OS does to them when they page fault or similar.
It is quite possible for applications to be quite resiliant, when using
real operating systems. Tandem non-stop comes to mind, and they're still >chugging away (HPE).
I am starting work on creating a new Python implementation from scratch[snip]
On 11.02.2021 13:29, Mr Flibble wrote:
I am starting work on creating a new Python implementation from scratch >[snip]
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 593 |
| Nodes: | 10 (2 / 8) |
| Uptime: | 71:46:43 |
| Calls: | 6286 |
| Calls today: | 9 |
| Files: | 181857 |
| Messages: | 1246630 |
| Posted today: | 2 |