Printing in Linux with threads: Application Closes

[lainz]

Hi, I'm using the printers unit. In the main thread there's no problem, but using it on a separate thread causes the application to exit.

Is something I'm doing wrong? Or that unit does not support threads?

I'm using the printer object is already created in that unit.

Code: Pascal  [Select][+][-]

1.       begin
2.  
3.         try
4.           gbImprimiendo := True;
5.           printer.SetPrinter(sImpresora);
6.           printer.Title := 'POSBerry - Comanda';
7.           printer.RawMode := True;
8.           printer.BeginDoc;
9.  
10.           for i:=0 to List.Count-1 do
11.             printer.Write(List[i]);
12.  
13.         finally
14.           printer.EndDoc;
15.           List.Free;
16.           gbImprimiendo := False;
17.         end;
18.       end;

[lainz]

Any ideas? 

[MarkMLl]

This is not an area in which I profess any expertise whatsoever. However in order to try to keep the ball moving and noting your courteous delay before prodding I think that there are two questions to be asked.

The first is whether, when run from a shell session, the program reports any exceptions.

The second is whether initiating the printing activity via the thread's Synchronize() improves reliability.

MarkMLl

[winni]

I'm using the printer object is already created in that unit.

Hi Lainz!

Oh oh - and another thread uses the same var printer and the main thread uses the same var printer ....

That's not a good idea.

But why do you need a thread?

Windows has a print spooler.
Linux in a better way the same.
And if your print direct to a printer:  Nowadays all printers have some MB buffer.
So your job should in a second vanish from your app.

Winni

[lainz]

Thanks for the replies. On Windows seems that there's no problem. But on Linux it crashes.

Maybe we need to do it synchronized anyways, because the same printer can't print two things at the same time.

We're using a REST API made with lazarus for a GUI application, that receives the data to be printed. That runs in a separate thread and for that the question. I've moved the code with Synchronize() and it works.

[MarkMLl]

Maybe we need to do it synchronized anyways, because the same printer can't print two things at the same time.

You're missing the point. MUCH nearer to the code you're writing, if the printing stuff provided by Lazarus isn't guaranteed to work reliably when called from a thread then you need Synchronize().

All considerations of printer sharing and document spooling are much more remote: it's what operating systems are for.

MarkMLl

[Thaddy]

You're missing the point. MUCH nearer to the code you're writing, if the printing stuff provided by Lazarus isn't guaranteed to work reliably when called from a thread

No, Mark, you need WaitFor.... not synchronize..
Why? Easy. Under both Linux and Windows you need to make sure the application is terminated *after* the thread has finished it job.
The alternative is to not use a thread, but a separate process.

[MarkMLl]

You're missing the point. MUCH nearer to the code you're writing, if the printing stuff provided by Lazarus isn't guaranteed to work reliably when called from a thread

No, Mark, you need WaitFor.... not synchronize..
Why? Easy. Under both Linux and Windows you need to make sure the application is terminated *after* the thread has finished it job.
The alternative is to not use a thread, but a separate process.

(Thinks, rereads thread...) OK, OP says that he's using the printers unit, while I was assuming that he was using something provided by the (Lazarus) LCL.

I'm still somewhat dubious as to whether this is thread safe (on all platforms): can you say anything conclusive about that?

MarkMLl

[Thaddy]

There are actually some more concerns:
1. we have a printer unit.
2. we have a printers unit.

*1 is a line printer unit from the DOS era, basically writeln(<device>, <content>)
*2 is a more modern unit and e.g. on Windows should access the printer queue.

In principle both are threadsafe, but both need to exit cleanly. Hence waitfor.
The second option should be more forgiving, though, because it already delegates the job to the OS printer queue.
Hence more likely to print even if the application is not terminated correctly.

[MarkMLl]

I am very happy to defer to your experience in this area :-)

MarkMLl