I was just looking over the router logic online at sourceforge (RPGUIRTR.RPGLE) @ revision 7.
I expect you’re still working on this so it may be premature but nonetheless.
I am wondering if the delay in the spawn processing is a bottleneck?
//?Pause long enough for the client job to initialize
rc = sleep(2);
What would happen if it gets hit with 5 requests in the one second? Does that mean the router won’t start spawning the last one until the 9th second?
Could the spawned processes instead tell the router that they are ready, via a second dtaq read by the router when required, and thus save the router from waiting at all.
I might be missing something and I’ve not run the code, just trying to grok the thing.
Darron.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Aaron, Rory, et al.
I was just looking over the router logic online at sourceforge (RPGUIRTR.RPGLE) @ revision 7.
I expect you’re still working on this so it may be premature but nonetheless.
I am wondering if the delay in the spawn processing is a bottleneck?
What would happen if it gets hit with 5 requests in the one second? Does that mean the router won’t start spawning the last one until the 9th second?
Could the spawned processes instead tell the router that they are ready, via a second dtaq read by the router when required, and thus save the router from waiting at all.
I might be missing something and I’ve not run the code, just trying to grok the thing.
Darron.
Darron,
You are correct - the sleep is indeed a needless bottleneck, but luckily, I've rewritten the whole router…
The new version does exactly what you suggest - it waits for the client to tell it (via a data queue entry) that it has finished initializing.
The new version will be posted asap…
Rory