NT Service Control Manager

[John E. Malmberg]

Luke Kenneth Casson Leighton <lkcl#samba.org>


>On Mon, 20 Dec 1999, John E. Malmberg wrote:
>
>> The platform I am using will not support a lot of short lived
>> spawned processes.
>
>what do you mean, won't support.  this is at user-interface speed,
>therefore are you talking about speed of fork()?


Yes, actually.  I am running on OpenVMS, and it does not have a fork().

It has a vfork()/exec() pair, that basically starts up the image again in a
child process, but at the point of the vfork() the child will take the other
branch.

As you can see from that description, that can be a costly operation.  Just
the action of a process create on OpenVMS is a relatively costly compaired
to UNIX.

It does not become an issue with relatively long lived programs such as
smbd.  As I stated in a previous post, on OpenVMS, each instance of smbd is
launched by the TCP/IP program when a request comes in on that port.

>i'd like to do some sort of optimisation, such that if you receive a
>NetServerGetInfo followed immediately by a NetShareEnum (run SRVMGR.EXE
>and pick a box, you'll see what i mean: all those dialog boxes are filled
>in with NetServer* MSRPVC calls), then the srvsvcd spawned for the
>Net5ServerGetInfo does not immediately die: it can then be used to service
>the NetShareEnum.


If it is a process that I can launch from the TCP/IP dispatcher program, and
then it sticks around for a while, that will not be too much of a problem.
It is fastest though if I have a daemon up to respond already.

>i have some plans... :)


As the discussions threads have indicated. :-)

I am mainly concentrating on getting ALL of the main functions of the
released version of SAMBA to run on OpenVMS, with as few source changes as
possible.  But I suspect the majority on this list is not interested in
those details.

-John
wb8tyw at qsl.net