Search the Community

I have to update an application that has 20 threads running at the same time and each thread is requesting an XML through an http connection. In order to process the received XML, each thread has to use data from 14 TFDMemtables. The Threads are the same running all the time and the TFDMemtables they use are also the same, The TFDMemTables' data are static, received from an external database when application starts, not need to be updated/edited as the application runs. I read that with TFDMemTable you can use clonecursor and have different TFDMemTable object instances with the same data. I though that I could create such a TFDMemTable for each thread before threads start to use them. My question: Can different threads use TFDMemTables object instances (created with data from clonecursor) from an initial TFDMemTable? Is this threadsafe? Thank you in advace

I need to run a piece of code in TTask threads using a thread pool, that runs in every platform and get the results in the main UI thread in a thread safe message object without checking with a timer. Inspired by a post from Remy Lebeau in the Lazarus forum I wrote the following. Comments, suggestions, errors in the code welcome. interface type TTaskdata < T >= class type mydataP = ^T; mytaskproctyp =procedure(a: mydataP) of object; private Data: T; ProcessData: mytaskproctyp; procedure DoProcess; public procedure queue(datatyp: T; taskproc: mytaskproctyp); end; implementation procedure TTaskdata<T>.queue(datatyp: T; taskproc: mytaskproctyp); begin Data := datatyp; ProcessData := taskproc; TThread.queue(nil, DoProcess); end; procedure TTaskdata<T>.DoProcess; begin ProcessData(@Data); end; In an other/main Tform Unit type Dsoup = record nam: string; i: integer; end; // a sample record for send and receiving data to Ttask routine ReturnProc = procedure(mypointer: Ttaskdata<Dsoup>.mydataP) of object; var FCustomPool: TThreadPool; // the theadpool to be used for reusing threads, it should initialiazed in Tform's constructor procedure TForm1.Button1Click(Sender: TObject); // the initial route that will prepare data for Ttask and run it var soup: Dsoup; begin { set in Dsoup all data to send in TTask routine } TTask.Run(dowork(soup, getresults), FCustomPool); end; function TForm1.dowork(const a: Dsoup; p: ReturnProc): tproc; begin Result := // anonymous function to run by Ttask procedure var ff: Ttaskdata<Dsoup>; begin ff := Ttaskdata<Dsoup>.create; try { do all the task job here } ff.queue(a, p); // add result data to be sent with Thread.queue except ff.free; end; end; end; procedure TForm1.getresults(p: Ttaskdata<Dsoup>.mydataP); begin { here come the results from TTask in the main UI thread } end;

Hi there, I'm checking in iOS (and later for Android, Windows, etc.), what is the best, right way to Sleep in a background mode of the OS. The implementation for iOS seems to be same, as Posix, for iOS, Android, Macos, but I didn't checked that. My goal is to stop any OS operation in the background mode, to avoid killed apps by the OS. While the Thead loop is still active, but only throttled. TThread.Sleep - uses usleep, which is external function, as far as I know based on nanosleep - is this really affecting the current thread only ? class procedure TThread.Sleep(Timeout: Integer); begin {$IF Defined(MSWINDOWS)} Winapi.Windows.Sleep(Timeout); {$ELSEIF Defined(POSIX)} usleep(Timeout * 1000); {$ENDIF POSIX} end; System.SysUtils.Sleep - is bascially same {$IFDEF MSWINDOWS} procedure Sleep; external kernel32 name 'Sleep'; stdcall; {$ENDIF MSWINDOWS} {$IFDEF POSIX} procedure Sleep(milliseconds: Cardinal); begin usleep(milliseconds * 1000); // usleep is in microseconds end; {$ENDIF POSIX} System.SyncObjs.TEvent.WaitFor - is defintively based differently - uses a sem_timedwait (here and here also) - this probably waits by counting in a semaphore, so its not a "real" sleep of the OS, right ? Shall I better use Sleep or TEvent.WaitFor, to let threads sleep in the OS, while avoiding too many wakeups and operations in the background ? Is TEvent.WaitFor really sleeping, from a iOS OS perspective, or will it be seen as running app ? What I assumed before is that TThread.Sleep really stops the thread, and passes back CPU operation to other tasks, but I'm not so sure anymore under IOS.