dce/rpc "client" api
John E. Malmberg
wb8tyw at qsl.net
Tue Aug 22 13:24:29 GMT 2000
"Luke Kenneth Casson Leighton" <lkcl at samba.organization> wrote:
> in other words, immediately after an accept() there follows a fork(). just
> like in smbd.
> the consequences are that, apart from on VMS [discussions on this are in
> the samba-ntdom or samba-technical archives, dated approximately nov 99 -
> jan 2000] this is fully scalable. for each DCE/RPC connection, there is
> one DCE/RPC daemon.
> john has to solve the [expensiveness of the] VMS fork() issue for smbd
> anyway, so he would have to employ the same solution under the daemon
> architecture, too.
It has been reported on the comp.os.vms newsgroup that VMS will be getting a
working fork() function at some unspecified future version and date. There
are also some roadmap estimates on a presentation that indicates it will be
within a few years. There was no mention to making the select() function
work the way it does on most UNIX systems.
However, either path that is taken with Samba has significant impact to my
For shared libraries that are dynamically loaded, I can not reference
[easily] any global variables from the calling program.
I also think it is cleaner that a shared library not reference any external
address that was not passed to a routine that called it. It eliminates the
issue that Andrew Trigdell brought up about what happens if a global
variable changes. You simply take care to insulate yourself from that at
the design and implementation phase.
I do have an alternative that I do not think that UNIX has with implementing
something similar to fork().
If the code that does the "accept() followed by a fork()" can easily be
wrapped in a routine like:
In this case the completion of the accept() call would cause a new thread,
not a process to start up. Much less overhead, so the scalability is
However that has side effects that would cause a major rewrite of the source
code, as effectively I would be making the code multithreaded.
Basically to prevent blocking threads, I would have to have each routine
that does any I/O call schedule a followup routine and then return while the
I/O completes in the background. Also all thread global variables would
have to be tracked in one malloc() structure.
I bring these points up, because there may be some benefit from looking at
how to implement this from a UNIX perspective.
Putting the thread global variables in their own structure (if they are not
already there) can make the source code easier to follow, even in a program
structure that depends on using fork().
wb8tyw at qsl.network
More information about the samba-technical