On 10/26/21 9:18 AM, Patrik Schindler wrote:
Do I get this correct? You had a socket listener running (as
PJ?), and dynamically spawn workers?
I did something like that for my TCP servers. Although I had a user
configurable number of workers pre-spawned.

Like the Apache httpd does.

Essentially, yes. Different mechanism, same effect.

I didn't use PJ jobs ... I just submitted regular batch jobs to

I understand. But submitting these would impose a penalty in terms of
CPU spikes and time until the batch job is ready to run, and can
continue servicing requests from the socket connection. As said, I
want to make my idea run as efficient as possible on my 150. :-)

No real CPU spike, I don't think. The job submits and waits until the monitor job hands it work to do.

The data queue is used to hand the socket descriptor from the
monitor job to the worker job.

The socket descriptor is AFAIR just a number. Why not pass it as a
parameter? Or is "entry arrived in the *DTAQ" the signal for the
already running worker to, well, start work?

Ah, Sorry, I misremembered.

The data queue is used for the individual server jobs to send their internal job id's to the monitor job. The monitor job uses the job id to pass to the givedescriptor api.

The server job calls take descriptor which waits for the monitor job to
send the socket information to it.

In a nutshell...

The monitor job starts and launches n number of server jobs.
Each server job sends it's internal job id to a data queue
The server job then sits on takedescriptor until it's handed work to do

The monitor job gets a connection
It gets the next server jobs internal job id from the data queue
It calls the givedescriptor api with the server job's internal job id
It then spawns new server job to take the place of the server job that
was just handed a connection


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.