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
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
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
wb8tyw at qsl.net
More information about the samba-technical