Thank you Dear Remy
But I have an almost existential problem.
My application is an ERP. Assume this scenario.
The Accounting process prepares Account Summaries to clients by e-mail.
So, that process calls my "Preparer" process, made with TTask and create the e-mails by recording them prepared in that EMAILS table of an SQLITE database.
When the "Preparer" process finishes, it sends the message to the SenderEmails thread (SetEvent style) so, this thread starts sending them.
Now, thanks to the fact that these processes runs in the background, the user enters the Billing process. So, creates invoices to send to clients.
The Billing process calls the process "Preparer", creates the e-mails, records them...and sends the signal AGAIN to the SenderEmails thread...but this thread IS STILL BUSY SENDING the previous emails...
The SenderEmails thread has a method called "BeginDispatch", like this
procedure TSenderEmails.Dispatch;
begin
FEvento.SetEvent; //FEvento is a TEvent.
end;
procedure TSenderEmails.Execute;
begin
FEvento.ResetEvent;
while not Terminated do
begin
if FEvento.WaitFor(10000) = wrSignaled then
begin
//query the EMAILs table where SENT field is FALSE
//send the emails to the SMTP
FEvento.ResetEvent;
end;
end;
end;
Here comes my doubt:
The SenderEmails thread turns off the TEvent with ResetEvent when all e-mail are sent.
But before, another process had turned it on...isn't a concurrency problem occurring here?
A process sent a signal, the worker thread started working upon receiving that signal, but another process signaled the thread again...and the worker thread turned off the signals when finished.
So, is it possible to ACCUMULATE the signals so that they are not lost if several processes tell the EmailSender thread to proceed to work?
As you can see, it's more a design issue. What I'm looking for is that all this takes up the least amount of resources possible and it always runs in background.
Regards