promero

Hello Dear Friends, I have a problem and I would like to hear your opinion. It's in Delphi 11.2 I have 2 threads, one that "prepares" emails from templates and another, which is the one that sends them. The first thread, which manufactures/prepares the emails, stores them in an 'EMAILS' table in a SQLITE database, ready to be sent. It is inside a Task class. It works ok. The second thread actually sends the emails recorded in the 'EMAILS' table to the recipients. It is based on the Thread class. With every email sent, it updates the "SENT" column from EMAILS table, with "true" value. What I need: -I need the first thread "notify" the second thread "hey, I sent you lot of new emailss, please send them": that's it: send it a signal. If the second thread don't receive that signal, let it remain paused. -That the second threads, also sends an update of the sent emails to another process. This process is simply a Dbgrid showing the EMAILS table with a Column "Sent". I want that view to update 'sent' column...that is, to shows what the second thread is doing. Some suggestions? Many thanks Friends

Thank you guys! Remy and Kas Ob. One problem about desing is overthinking the future problems: these ideas unlock my problem.

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