VB6 MultiProcessing (StdExe-IPC via SharedMemory)

[couttsj]

I have a need is a work process to read the server data used winhttp or your http mod, processed and passed to the control main process to show, do not know if the work process will die. I haven't done this yet.

As far as I can tell, the worker thread remains in memory as long as the main thread.

J.A. Coutts

[Schmidt]

As far as I can tell, the worker thread remains in memory as long as the main thread.

To be precise, the WorkerProcess remains alive (assuming your own Worker-Functions don't cause an unhandled VB6-error-condition) until:
- the cIPCMaster-Object of the Main-Process calls its .CloseWorkerGracefully(TimeOutSeconds) method
- or is set to Nothing "roughly" (in which case it performs a Hard-Terminate of the Worker-Process)

There's also a third condition under which a WokerProcess automatically closes itself:
- if the Form.hWnd one has passed via InitAndBindWorkerTo(...) dies, the Worker will recognize this also and will automatically close
.. (this is BTW the mechanism which ensures automatic Worker-closing, when you press the Stop-Button in the IDE)

Ok, so the only other condition (the fourth one) under which a WorkerProcess can "go out" is the one I mentioned at the top of this posting:
- you run into an unhandled error-condition in your own Worker-Code
A cIPCMaster-Instance in your Main-App-Thread can always ask, whether a Worker ran into such a condition (is still alive) via:
oMaster.IsWorkerActive

If you poll that IsWorkerActive-Property against a given cIPCMaster-Instance, (e.g. when you manage a few of them in
a dedicated "Worker-Pool-Manager-Class") - you could easily react to "unexpected closing" of a worker, by removing
said Master-instance (which only refers to a "dead worker") from your "Worker-Pool-Collection" - readding a new one instead.
This allows for an easy way to set up a real stable-working "WorkerPool-Manager-Process" (e.g. for a robust Server-Scenario).

As to your other question:

It seems to me that using a separate worker thread would be more efficient from a memory usage perspective.

An upstarted VB-Process (with no GUI) consumes about 1.5MB of memory...
So, yes - that's a bit more overhead than an upstarting "normal thread" would consume (memory-wise).
But these days, I'd consider that amount of memory-overhead not really "an issue" (even if you run a pool of 16 Workers or so).

HTH

Olaf