Page 8 of 9
Re: atomic web server threads
Posted: Sat Jun 29, 2024 1:43 am
by skinkairewalker
hi idle , how u doing ?
These days ago I was testing the Tauri-App, for educational purposes...
and I noticed that it creates its own protocol: tauri://localhost
In purebasic would it be possible to do this kind of thing?
I did some searching, but I didn't find much that was useful/easy to do...
Would it have to be done directly on the http server?
Re: atomic web server threads
Posted: Sat Jun 29, 2024 2:26 am
by idle
it uses node.js. as a server, The whole point of atomic web server is to replace server side scripting languages and cgi so you can just use the native power of PB but yes it's still only http/https. I'm not sure what the benefits are for protocol handlers unless you could use pipes rather than tcp.
Re: atomic web server threads
Posted: Sat Jun 29, 2024 3:55 am
by skinkairewalker
idle wrote: Sat Jun 29, 2024 2:26 am
it uses node.js. as a server, The whole point of atomic web server is to replace server side scripting languages and cgi so you can just use the native power of PB but yes it's still only http/https. I'm not sure what the benefits are for protocol handlers unless you could use pipes rather than tcp.
awesome ! Thanks for the clarifications.

Re: atomic web server threads
Posted: Mon Jul 01, 2024 6:00 am
by skinkairewalker
I'm trying to study the server code with multhread, I'm a little confused in the part of receiving messages, a main thread is created, right?
for each message received, another thread is created to process the data, preventing another connection from causing the simultaneous flow of messages from the server to other users who send messages?
Sorry for the confusion in the words, I hope you understand what I meant... xD
Re: atomic web server threads
Posted: Mon Jul 01, 2024 10:17 am
by idle
A browser may open multiple connections to the server and then reuse them. so each connection creates a client thread with a queue which waits on a semaphore.
Re: atomic web server threads
Posted: Mon Jul 01, 2024 2:15 pm
by skinkairewalker
But what if there's a sudden surge in connections?
There are some studies indicating that a page shouldn't take more than 2 seconds to load... Is it possible for a slowdown to occur due to another connection that hasn't finished loading yet?
Re: atomic web server threads
Posted: Mon Jul 01, 2024 9:53 pm
by idle
If it's slow to load a page it could be blocking the page waiting on timeout. I've been fixing a few bugs but haven't finished testing yet.
If you try the emoji list on the atomic webserver test site it will take quite a time to download it's 39mb and if it fully loads you should see a notice at bottom of page with unicode org.
Re: atomic web server threads
Posted: Tue Jul 02, 2024 6:54 pm
by PBJim
idle wrote: Mon Jul 01, 2024 10:17 am
A browser may open multiple connections to the server and then reuse them. so each connection creates a client thread with a queue which waits on a semaphore.
Thanks for making this project available Idle, I think it is important to PB. Out of interest, when a thread is running and the browser that it was started for issues its next request, how does the main thread that handles the network client request get that request to the relevant thread?
You mention that you use a semaphore, but that's only a trigger, not an item of data to tell the thread what it wants it to do, so I'm interested in how you keep the thread open and receiving new tasks. Perhaps it's the queue that you refer to. Thanks again.
Re: atomic web server threads
Posted: Tue Jul 02, 2024 10:22 pm
by idle
It's using a list to queue the client requests. So the thread will keep going while there's a job to do or times out. Semaphore just keeps it ready to respond to 1st request and halt when there's no requests left. The browser will reuse the connections if they're kept alive.
Re: atomic web server threads
Posted: Wed Jul 03, 2024 1:32 am
by idle
version 3.1.0b9
Added TLS support to reverse proxy
Re: atomic web server threads
Posted: Wed Jul 03, 2024 9:40 am
by PBJim
idle wrote: Tue Jul 02, 2024 10:22 pm
It's using a list to queue the client requests. So the thread will keep going while there's a job to do or times out. Semaphore just keeps it ready to respond to 1st request and halt when there's no requests left. The browser will reuse the connections if they're kept alive.
Ah, thanks I see. So the threads would recognise anything pertinent to them by checking an identification in the queue list? Sounds good.
Re: atomic web server threads
Posted: Wed Jul 24, 2024 4:39 am
by skinkairewalker
idle wrote: Tue Jul 02, 2024 10:22 pm
It's using a list to queue the client requests. So the thread will keep going while there's a job to do or times out. Semaphore just keeps it ready to respond to 1st request and halt when there's no requests left. The browser will reuse the connections if they're kept alive.
Wouldn't this be a bit "disadvantageous" in case of 10 thousand simultaneous connections?
Re: atomic web server threads
Posted: Wed Jul 24, 2024 5:13 am
by idle
skinkairewalker wrote: Wed Jul 24, 2024 4:39 am
idle wrote: Tue Jul 02, 2024 10:22 pm
It's using a list to queue the client requests. So the thread will keep going while there's a job to do or times out. Semaphore just keeps it ready to respond to 1st request and halt when there's no requests left. The browser will reuse the connections if they're kept alive.
Wouldn't this be a bit "disadvantageous" in case of 10 thousand simultaneous connections?
No it makes it faster to respond if a connections is reused and frees the server thread up so it can deal with other connections.
Re: atomic web server threads
Posted: Tue Jul 30, 2024 6:42 pm
by skinkairewalker
awesome !!!
Based on the atomic web server 3 code, I'm studying how to make a tcp/udp multithreaded socket server, thanks to you, I'm understanding how it works.
Re: atomic web server threads
Posted: Fri Aug 02, 2024 3:26 pm
by skinkairewalker
I was studying about threads on the server, and I noticed that there is a mutex to lock the execution of the thread until it ends, right?
I was thinking, in an environment where each execution performs a query on the database that takes several seconds to complete, what to do in these cases?