NoOp wrote:
On 11/05/2008 07:30 AM, Kun Niu wrote:
Dear all,
I'm trying to transform many office documents into pdf files all at
once on Linux with soffice run in daemon mode.
It seems that the documents are processed one by one even though they
are sent to different processes listening on different port.
What I want is that all the documents can be processed simultaneously.
Thanks in advance for any hints or advice.
Perhaps:
<http://www.google.com/search?complete=0&hl=en&q=openoffice+%2Bbatch+pdf&btnG=Google+Search>
will provide possible solutions. First hit:
http://www.oooninja.com/2008/02/batch-command-line-file-conversion-with.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
=====================================
I took a look at the URL's. Very good.
Let me see if I can shed some light on something here.
Simultaneously? In literal truth - NO, not on a single CPU machine.
Per CPU the OS operates it in a time slice fashion. A bit of CPU time is
allocated to each program and system function in order and then it moves
to the next, 'round and 'round the queue it goes. This gives the
appearance of simultaneous actions. It is also the factor that accounts
for 'a slow machine'. The more the load for a given machine the slower
it seems to run. The CPU hasn't slowed, just had further to run.
Just how big is your big bad mean machine?
16 100GigaHertz CPUs with 16 100GigaHertz busses and solid state core?
Or
800MHz, with 60MHz buss and 5,000RPM hard drives?
Don't answer that. It is just to make the point.
Obviously there are ways to test load vs completion time.
instructions to swriter file.in file.out &
instructions to swriter file1.in file2.out &
instructions to swriter file2.in file2.out &
.
.
.
(and so on) Will, at some point, overload the machine.
IF the core dispatcher for swriter, the one that fetches lib functions,
isn't properly threaded, it will overload the OS.
Each thread is supposed to operate on an independent time slice. In this
case there should be a separate thread for each file. From the sounds
of things ("seems to do one at a time") - there is not. Since OOo was
getting popular before threads were I would not be surprised to learn it
is "still" wired for single user machines. Proper use of threads is
still more art than science. The more threads the further around the
queue. Short processes are best left in the code as not threads. Small
program logic changes can create large numbers of threads. Tweaking can
take a long time.
If the lib fetch section is still 'single user' minded it is likely it
queues the files and processes in sequence. No work around. It needs to
be in each swriter instance. Multiple swriters, multiple lib fetchers
rather than a single one.
Someone who has access to the coders needs to have a conversation and
post some "User Can Expect" guidelines. It's been a solid 30 plus years
and like owners of the car and the plane, the computer users are more
savvy and more demanding of more productivity. As they should be.
Steve
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
