NT Service Control Manager

John E. Malmberg wb8tyw at qsl.net
Mon Dec 20 03:34:15 GMT 1999

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

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.

wb8tyw at qsl.net

More information about the samba-technical mailing list