seninha has quit [Remote host closed the connection]
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
m_mans has joined #picolisp
m_mans has quit [Remote host closed the connection]
m_mans has joined #picolisp
m_mans has quit [Remote host closed the connection]
m_mans has joined #picolisp
m_mans_ has joined #picolisp
m_mans has quit [Read error: Connection reset by peer]
m_mans_ has quit [Ping timeout: 265 seconds]
m_mans has joined #picolisp
m_mans has quit [Remote host closed the connection]
m_mans has joined #picolisp
m_mans has quit [Ping timeout: 246 seconds]
calle has joined #picolisp
m_mans has joined #picolisp
m_mans has quit [Remote host closed the connection]
seninha has joined #picolisp
calle has quit [Remote host closed the connection]
<beneroth>
abu[m], what is a good way to get the file descriptor in the parent of a child process pipe (for a certain child Pid as returned by (fork)) ?
<abu[m]>
I think accessing /proc/<pid>/..
<beneroth>
the parent has a pipe to the child, right
<beneroth>
e.g. used by (tell), but for the picolisp user we work only with child Pid not the fd to it
<abu[m]>
or ask the parent via (tell 0 tell <myPid> ... setq ...
<beneroth>
I'm in the parent. I like to have the fd number of a specific child pipe
<abu[m]>
Is it an implicit pipe?
<beneroth>
yeah, well the standard picolisp IPC one established during (fork)
<abu[m]>
I see, so it is not clear which pipe
<abu[m]>
So the way is parsing /proc/<pid>/fd
<beneroth>
hmmm okay.. then it's probably better to just establish another explicit pipe from parent to child process
<abu[m]>
Don't remember, it was 13 years ago it seems ;)
<abu[m]>
Parsing just pipes is a lot easier
<beneroth>
yeah I see where it is going, thanks :D
<abu[m]>
I hope it is useful ☺
chexum_ has joined #picolisp
chexum has quit [Quit: No Ping reply in 180 seconds.]
m_mans has joined #picolisp
<aw->
hi beneroth! you might want to look into "named pipes" as well, you create them in the parent (or child) and can communicate between them by just writing commands (ex: PLIO) to the file
<beneroth>
aw-, yeah thanks. I know about it roughly, though no hands-on experience yet :)
<aw->
mkfifo childpipe; mkfifo parentpipe;
<abu[m]>
beneroth: Why do you need the descriptor?
<beneroth>
haha, right question
<beneroth>
I want to transfer connected sockets using sendmsg() to worker processes, instead of proxying
<beneroth>
abu[m], any reason you didn't use this in httpGate?
<abu[m]>
For one, you cannot send pipe descriptor to another process
<abu[m]>
And, how could I use it in httpGate?
<abu[m]>
httpGate's main task is TLS handling
m_mans has quit [Remote host closed the connection]
<beneroth>
I would want to send the client socket descriptor, instead of proxying the connection
<abu[m]>
Yes, but httpGate does the en/decryption first, so it cannot be delegated
<beneroth>
abu[m], are you sure about pipe descriptors not being transferable? I understand sendmsg() as usable for transferring all kinds of file descriptors. but haven't tried getting it working yet.
<beneroth>
abu[m], true
<beneroth>
yeah right
<beneroth>
my question was stupid from the beginning :)
<beneroth>
(about httpGate)
<abu[m]>
A pipe descriptor is a normal file descriptor. In my understanding open file are a property isolated in a process. On the other hand, I never investigated sendmsg(), so I'm not sure
<beneroth>
it's basically giving another process access to the kernel file description object
<abu[m]>
OK, yes, so this sounds reasonable
<beneroth>
the actual fd number is of course specific to each process, so might differ.
<beneroth>
lets see.. I'm fumbling and trying out bit.. will report when I get to any useful findings :)
<abu[m]>
Then the best is to write a small libb in PilSrc (like ext.l or ht.l) which extracts the FD from the 'child' structure
<beneroth>
yeah I guess! I mean tell implementation must know the fd :)
<beneroth>
basically I just wanted to re-use the existing pipe between picolisp processes for a non-pil (non-plio) transfer
<abu[m]>
yes (tell impl)
<beneroth>
I figure this should be ok, if after the action the pipe is in normal state again, and as long as not one of the involved processes uses (wait) (indirectly or directly) to listen to the pipe
<beneroth>
hmmm
<beneroth>
probably better to open a dedicated pipe xD
<abu[m]>
yeah
seninha has quit [Quit: Leaving]
seninha has joined #picolisp
genpaku has quit [Remote host closed the connection]