spoolss_notify_cjobs()

[Andrew Tridgell]

Luke,

> consequently, a single-process implementation such as spoolssd, is going
> to run into problems.
> 
> this will require some form of "emulation" of threads, to fix in a
> portable manner.

I don't think that is the right conclusion. 

The reasons I don't want to go to a threaded system for rpc (even an
emulated one) are as follows:

1) rpc calls are not performance sensitive

2) very few rpc calls have any possibility of blocking. Calls that
   don't block don't cause any problems.

3) for those rpc calls that can block we can solve the problem fairly
   simply without setting up a complex thread emulation system.

We have a "thread emulation" system in nmbd, and it makes nmbd much
more complex (and bug prone) than it otherwise would be. It is
unfortunately needed for nmbd, but you should note that despite having
this thread system we still needed to add the async-dns process
because a in-process thread system does not overcome the fact that
some operations on unix systems block the whole process. In that case
the problem was the resolver library, and the right solution was the
async-dns process that provides async access to the resolver library.

> also been talking to andrew about a possible diagnosis that lack of
> threads in samba is causing a benchmark program where the NT SMB client
> *is* threaded is causing similar "blocking" problems in the benchmark
> program.

I'm actually very skeptical about your diagniosis of that problem. The
way you described the benchmark to me it doesn't make any sense for
this to be a thread problem. Once we get hold of the benchmark code
(or binaries) and look at it carefully then we will be able to make a
prpoper diagnosis, but meanwhile I think that using this as a reason
for pushing for a thread emulation system is premature.

> The spoolss_notify_cjobs() (called as a result of
> api_spoolss_rfnpcnex()) forks and waits for the child
> to exit.  However, when the printer is unable (remote one 
> of course) the child hangs until it times out.
> 
> I'm working on the code, but if someone has a 
> quick fix....let me know.

Gerald, this has been a problem with printing in Samba for years, well
before we added spoolss. The solution I added several years ago was a
quick fix that added the "lpq cache time" parameter and added some
simple cacheing of lpq results. This reduced the impact of the
problem, but didn't eliminate it entirely. In the new printing backend
I did a couple of months ago I cleaned up this fix quite a lot, but it
is still just a cache system and as such does not completely solve the
problem.

I think we now have the infrastructure to do something a little
better. We now have an internal print queue database in Samba, which
means we have accurate and immediate info on all printing actions
taken by SMB clients. What we could do is not call out to lpq
synchronously like we currently do, but instead fork a child to call
lpq and get the child to update the print database. The parent would
just return whatever info it currently has and let the child update
the print database when it can.

I suggest we do this based on a parameter "slow lpq", and use a marker
in the tdb to say that there is currently a lpq being run for that
queue so we don't end up spawning multiple lpq runs at the same time
for the same queue.

I am willing to consider doing a packet queue system in the rpc server
code (like we have in nmbd) but I think that we'd need a stronger
justification than this problem. It would make the code a lot more
complex.

Cheers, Tridge