pablo_escoberg has quit [Ping timeout: 245 seconds]
rob_w has joined #picolisp
msavoritias has joined #picolisp
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
<beneroth>
abu[7], two questions
<beneroth>
1. while 'sort is destructive, 'by is not as 'by is building always a new list first, right?
<abu[7]>
Yes, that's right
<beneroth>
2. is 'close intended to be used on socket descriptors (as returned by 'port) too? or can socket descriptors only get cleanly closed by ending the process?
<abu[7]>
No, 'close' is for any file descriptors, also sockets
<abu[7]>
See e.g. (vi 'http)
<abu[7]>
It does (task (close *HtSock)) several times
<beneroth>
right.. damn right I should know this
<abu[7]>
also other places in lib/http.l
<abu[7]>
No worries :)
<beneroth>
I have a question about http.l btw. server function
<abu[7]>
ok
<beneroth>
this is deep internals, so maybe less important for others here.. but anywayx
<beneroth>
you explained to me before, I think, but I didn't take notes on the detail and forgot again...
<beneroth>
(task *Sock (http @))
<beneroth>
(http *Sock)
<beneroth>
(or *SesId (bye))
<beneroth>
why the (task *Sock (http @)) when 'http is called right after it and installs the task anew just after that call?
<beneroth>
my understanding:
<abu[7]>
This is for http2
<beneroth>
oh...pipelining
<abu[7]>
there may be several transactions over a single connection
<beneroth>
I see
<abu[7]>
T
<beneroth>
yeah, and in http2 also in parallel
<abu[7]>
yes, but Pil processes them sequentially
<beneroth>
(which was actually also an HTTP/1.1 feature, but servers largely never implemented it, so browsers stopped using it.. in my view HTTP/2 and HTTP/3 is all bullshit, they should just have added pipelining in 1.1 again...)
<abu[7]>
I see
<beneroth>
ok, so all that task installation does is queing another 'task
<beneroth>
which again is anyway happening after the session check
<beneroth>
so... is it needed?
<abu[7]>
You mean, the task never fires?
<beneroth>
well the second task installation is also doing accept
<beneroth>
I guess it can fire, but would newly sent client requests (on the existing socket) not anyway trigger the task installed just after the (http) call?
<abu[7]>
yes, *new* transactions
<beneroth>
accept is blocking, right?
<abu[7]>
yes
<abu[7]>
can block
<abu[7]>
hmm, not sure
<abu[7]>
listen surely blocks
<beneroth>
well its only called when there is already incoming data signaled by triggering the task
<abu[7]>
yes
<beneroth>
so it should not block, the way it is used here
<abu[7]>
listen also calls accept
<beneroth>
hm.. then accept is non-blocking and listen adds the waiting/blocking?
<abu[7]>
(vi 'accept)
<abu[7]>
it sets "nonBlocking"
<beneroth>
yep I just saw it this second :D
<abu[7]>
So only 'listen' blocks in 'wait'
<beneroth>
yeah, listen is only looping with wait and accept
<beneroth>
very simple
<beneroth>
still I don't understand the reason for that task installation
<abu[7]>
I think it made sense
<abu[7]>
Perhaps only if 'wait' is called somewhere during the first 'http'
<abu[7]>
if session, it of course always makes sense
<abu[7]>
Must go, bbl
<beneroth>
ok, cu later
<beneroth>
let me know when you are back and we can continue :)
<beneroth>
thanks!
rob_w has quit [Quit: Leaving]
<abu[7]>
Now on my way back
<beneroth>
no hurry. Also I'm now away bit. so lets talk tomorrow ;-)
seninha has quit [Quit: Leaving]
<abu[7]>
Yeah, better
msavoritias has quit [Remote host closed the connection]