Helo Richard,
Am 08.12.2025 um 17:26 schrieb Richard Schoen <richard@xxxxxxxxxxxxxxxxx>:
Wrote this little item about speeding up open-source PASE threads by using pre-start jobs. Try it out and feel free to share your feedback.
This is really interesting! Especially because my main machine is also on the low end of CPU power. Age-related, though. Not because of LPAR imposed limitations.
First, I wonder if this technique could be used to speed up network connections to inetd, being a part of OS/400 for a long time. On my 150, overhead to accept connection to program being started through inetd requires 1-2 seconds until it's ready for use. Inetd on the other side is a very handy thing, because your application doesn't need to be network aware. It talks solely to stdin/stdout, and those are redirected to network sockets by inetd. So, using inetd in conjunction with prestart jobs seems a good fit to me.
https://en.wikipedia.org/wiki/Inetd
(Dunno of the following might be better redirected to the C400-List.)
On Unix, TCP servers are usually implemented by a main worker process which triggers a fork() call to clone itself upon receiving an incoming connection through the accept() call. The latter creates a new file descriptor for talking to the established TCP channel. This technique allows to still listen to the original port in the "main" application, while actual handling of established TCP communications is done by a child process. This is a very common pattern and very handy for implementing non-blocking TCP servers, allowing multiple concurrent connections.
The "UNIX C Applications Porting to AS/400" (SG24-4438) and associated companion guide (SG24-4938) mention that OS/400 and successors have no fork(), but spawn(). The latter can allegedly be used to mimic fork() to some extent regarding the inheritance of file descriptors/network sockets. Details escaped my memory, though. The examples in the IBM documentation and from e. g. Chris Hird in his "Let's C" course use separately coded workers, while I want to mimic the self-contained approach of Unix C with fork. I have not yet tried this but in my head. But xmas holidays approach quickly. :-)
Building upon this, I want to have a set of prestart workers to which incoming tcp connections are handed over for actual processing. Thinking a bit more, this feels quite akin to the older "prefork" process model of the Apache httpd on Unix, although there is no separation of program activation and running.
For both use cases, I should get a better understanding what exactly a prestart job is, and how its transition from dormancy to actually run can be triggered, or how to "hook" into it as in the examples above.
Thoughts and comments welcome!
:wq! PoC
midrange.com
