iv_popen(3)
β¨ iv_popen β bestie edition β¨
okay so this is from the ivykis programmer's manual, and it's literally about IV_POPEN_REQUEST_INIT, iv_popen_request_submit, and iv_popen_request_close β which is just popen(3) but for ivykis apps π«Ά
πΈ NAME πΈ
IV_POPEN_REQUEST_INIT, iv_popen_request_submit, iv_popen_request_close β it's giving popen(3) but make it for ivykis applications π
π SYNOPSIS π
#include <iv_popen.h>
struct iv_popen_request {
char *file;
char **argv;
char *type;
};
void IV_POPEN_REQUEST_INIT(struct iv_popen_request *this);
int iv_popen_request_submit(struct iv_popen_request *this);
void iv_popen_request_close(struct iv_popen_request *this);
like. that's the whole vibe. no cap. β¨
π¦ DESCRIPTION π¦
okay so iv_popen hands ivykis(3) applications an asynchronous version of popen(3) β and the way it's fully integrated with the ivykis event loop?? obsessed ππ
So here's the routine, bestie. First you initialise your struct iv_popen_request object using IV_POPEN_REQUEST_INIT, and you assign its ->file, ->argv, and ->type members. Once that's done, you can call iv_popen_request_submit on it. What happens next is:
- it forks off a child process π±
- that child will call
execvp(2)on->fileand->argv - meanwhile, back in the parent process, you get returned a file descriptor that's connected to the child's standard input (if
->typeequals"w") or the child's standard output (if->typeequals"r")
so basically you get a pipe to your new little buddy. iconic.
When your application is done with the child process, it should call iv_popen_request_close and close the file descriptor that iv_popen_request_submit returned. and listen β that close is not done automatically, okay?? not me forgetting to close my fd π you have to do it yourself, fr fr.
Also, iv_popen keeps monitoring the child's process state the whole time it's running, by registering an iv_wait(3) interest for its process ID. main character energy: it never stops watching π
Now for the part where we get a lil serious. If the child process hasn't terminated yet when iv_popen_request_close is called, iv_popen will attempt to terminate that child process in the background by sending it a series of SIGTERM and SIGKILL signals. π so yeah, it will absolutely end things if it has to.
π¨ important bestie alert:iv_popen_request_closemust be called from the same thread thativ_popen_request_submitwas called from on this object. like, same thread, same object, no switching up. periodt.
π SEE ALSO π
ivykis(3)iv_wait(3)execvp(2)popen(3)
go read them, iykyk π§
okay that's the whole page, bestie!! this one's from the ivykis manual, dated 2010-09-04 β and yeah it's been serving since 2010, we love a vintage slay πβ¨ mwah, go fork something responsibly π π
π¦ where this page comes from
- alpine 3.22: ivykis-doc 0.43.2-r0 Β· LGPL-2.1-or-later
- alpine 3.23: ivykis-doc 0.43.2-r0 Β· LGPL-2.1-or-later
- alpine 3.24: ivykis-doc 0.43.2-r0 Β· LGPL-2.1-or-later
- debian bookworm: libivykis-dev 0.42.4-1
- debian trixie: libivykis-dev 0.43.2-1+b1
- epel 10: ivykis-devel 0.43.2-2.el10_0 Β· LicenseRef-Callaway-LGPLv2+
- epel 9: ivykis-devel 0.42.4-7.el9 Β· LGPLv2+
- fedora 43: ivykis-devel 0.43.2-4.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: ivykis-devel 0.43.2-4.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 44: ivykis-devel 0.43.2-5.fc44 Β· LicenseRef-Callaway-LGPLv2+
- fedora 44: ivykis-devel 0.43.2-5.fc44 Β· LicenseRef-Callaway-LGPLv2+
- nixpkgs unstable: libivykis 0.43.2
- opensuse-leap 16.0: ivykis-devel 0.43-bp160.1.12 Β· LGPL-2.1-only
- opensuse-leap 16.0: ivykis-devel 0.43-bp160.1.12 Β· LGPL-2.1-only
- opensuse-leap 16.0: ivykis-devel 0.43-bp160.1.12 Β· LGPL-2.1-only
- opensuse-leap 16.0: ivykis-devel 0.43-bp160.1.12 Β· LGPL-2.1-only
- ubuntu jammy: libivykis-dev 0.42.4-1
- ubuntu noble: libivykis-dev 0.43-1build1
- ubuntu questing: libivykis-dev 0.43.2-1
- ubuntu resolute: libivykis-dev 0.43.2-1build1
- ubuntu stonking: libivykis-dev 0.43.2-1build1
- Copyright (C) 2010 Lennert Buytenhek
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms