seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
rob_w has quit [Remote host closed the connection]
<abu[7]>
beneroth: Remember we discussed the internal machinery of 'server' a while back?
<beneroth>
yeah?
<abu[7]>
I made an interesting extension
<abu[7]>
a single-shot (non-forking) mode
<beneroth>
a non-forking single-shot?
<abu[7]>
(server Port "!foo" T)
<abu[7]>
i.e. an optional 'flg'
<beneroth>
whats the behaviour?
<abu[7]>
The application code stays the same
<abu[7]>
But the server does not for
<abu[7]>
for
<abu[7]>
grr
<abu[7]>
fork
<abu[7]>
The session runs in the same process
<beneroth>
I'm still experimenting with persistent/long-living children as request handlers, but only on the side, haven't found the time to test it much
<beneroth>
do you use co-routines?
<abu[7]>
Yes, but this is independent of that
<abu[7]>
In the test setup here, it makes no sense if another session is started
<beneroth>
ah it's for single-user mode?
<abu[7]>
the session uses too many resources
<abu[7]>
yes
<abu[7]>
special case
<beneroth>
ah I see, yeah that is a legitimate scenario
<abu[7]>
PilBox could be such a case too
<beneroth>
then you can work directly in parent process, right?
<beneroth>
yes,absolutely
<abu[7]>
exactly
<beneroth>
yeah I actually have also made that for a single-user web-app (running only on localhost). but also haven't find the time to get far, just got the basics working xD
<abu[7]>
ok
<abu[7]>
Let's see what else it might be useful for :)
<beneroth>
so you could integrate these two use cases (classic pilabb/httpgate child-per-session vs. single-user webapp) into the existing (server) and http functions?
<beneroth>
because they are quite intertwined to work well :)
<beneroth>
(server) itself can be written very generally, but as soon as it goes into cleaning up children depending on client behavior it gets more complex
<abu[7]>
There is no clear distinction, yes
<abu[7]>
Usually the server does not clean up the children
<beneroth>
I used a general forking (server) implementation for a while, for both http and also an ftp server.. forking is easy generalizable for many protocols and use cases
<beneroth>
but long-running children make better use of database caching, and caching in general
<abu[7]>
Can't any child simply run for a long time?
<beneroth>
sure
<abu[7]>
So you mean a single child handles many separate sessions?
<beneroth>
but forking one-shots is more fragile, long-running children which are not session-bound must be able to recover from errors cleanly or there must be a way to restart them
<abu[7]>
Could be done with coroutines
<beneroth>
yeah
<beneroth>
that I mean
<abu[7]>
yes, fragile
<abu[7]>
If the session terminates, the server must be restarted
<beneroth>
coroutines might be a way to make it into a "event-driven" system, like e.g. nginx
<abu[7]>
yes, via tasks
<beneroth>
yes
<abu[7]>
I use in PilBox to sync the BTG DB
<abu[7]>
a thread permanently synchronzing
<abu[7]>
I just wanted to inform you
<abu[7]>
as I had to look at server again
<abu[7]>
and last time we were both wondering how it works ;)
<beneroth>
I think I start first with non-async handling of requests within a child (so one child only handles one request at the time, vs. task system with co-routines could potentially handle multiple requests concurrently
<beneroth>
yeah thanks
<beneroth>
much appreciated :)
<abu[7]>
:)
<beneroth>
current idea is to store session in database. if the same session-client ends up in the same child process, the caching can be used. if it hits another, cache-invalidation is correctly handled by standard database coordination.
<abu[7]>
interesting
<beneroth>
this is different (and a bit overhead) over the standard architecture with form.l but should be able to scale up without running into the fd limit, right?
<abu[7]>
yes, but a single process also does not scale well
<beneroth>
could have better performance for cases where multiple sessions read the same data
<beneroth>
T
<abu[7]>
So you combine both?
<beneroth>
yes. multiple long-running child processes which can handle requests across sessions.
<beneroth>
just the idea so far, not tested thoroughly yet :/
<abu[7]>
ok
isaneran has quit [Ping timeout: 260 seconds]
seninha has quit [Ping timeout: 252 seconds]
seninha has joined #picolisp
msavoritias has quit [Remote host closed the connection]