Re: Multiple DLL, multiple THREADS, multiple applications or something else?
From: Martin James (mjames_falcon_at_dial.pipex.com)
Date: 12/02/03
- Next message: Sven Pran: "Re: Application not run under Win9x"
- Previous message: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- In reply to: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- Next in thread: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- Reply: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 2 Dec 2003 12:37:32 -0000
"Kresimir Majdenic" <kresimir.majdenic@os.hinet.hr> wrote in message
news:3fcc738a@newsgroups.borland.com...
> Thank you very much
>
> ... I guess I will go for DLLs ... currently I am trying to figure out how
> to utilize TComPort without having multiple Forms visible on Desktop and
> also how to solve a problem with:
>
> 1. Once DLL is loaded and serial port opened and DLL left in its own
thread
> to wait for Rx event on designated serial port ... how to deliver data to
> main application once the Data arrives on serial port?
Well, there are a number of ways. Delphi has a 'synchronize' method that
'sort' of' works from a DLL. Thre have been some problems, I have heard.
This method was changed somewhere after D5 & now has some polling, a step
backwards IMHO. I prefer using postMessage to send buffer/data objects to
the main app. This works very well, especially if you re-use the buffers by
pooling them & so avoiding all those memory-management calls. PostMessage
is queueing comms so the thread does not have to wait after posting off it's
object - it can start straightaway fillling up a new buffer with data. The
snag is that the postMessage API is .NET-unfriendly, which, (apart from
screwing all my apps on .NET), my, or may not, matter to you. To use
postMessage, the DLL has to be told the handle of your main form.
> 2. How to deliver data to DLL (data required from database in order to
> respond to query from devices on serial port) on a notify base ... which
> means ... store data into DLL local record, notify DLL and return back to
> main thread - leaving DLL to deal with that data in its own thread?
Probably not necessary. The read& write serial calls can be made from
different threads. The thread that calls the DLL protocol handler, or
whatever, can sit there reading chars & sending off buffers while your main
thread, or some other database query thread, can send out query results no
problem.
You could, perhaps, do the queries direct from your read thread. You may
not want to do this as it cuts out the main thread completely & so it's more
difficult to display what is going on, but it would probably give the best
performance.
Another possibility is to use the main thread for just switching. Read
thread gets request data from serial port, does protocol & shoves the
request data into an object, together with everything else needed for a
reply. If the protocol is bad - send an error back directly, else it posts
the object off to the main thread, (and creates or depools another for more
serial data). The protocol parsers could be methods of your buffer object.
Main thead gets object, displays log stuff, dequeues a query thread & gives
it the object. The query thread performs the database query and, using the
info,methods/interfaces/whatever in the object, writes the reply to the
serial port that the query request came in on. The query thread then posts
the object back to the main thread & requeues itself, ready for another
query. The main thread gets the object, displays stuff, & then destroys the
object or requeues it for the next serial request.
With a little care, the data can flow nicely though your system without any
heavy loading on the main thread and with nothing having to unavoidably
wait, (unless you use .NET :).
Rgds,
Martin
> Any suggestion on that?
>
> Best regards, Kresimir
>
>
- Next message: Sven Pran: "Re: Application not run under Win9x"
- Previous message: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- In reply to: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- Next in thread: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- Reply: Kresimir Majdenic: "Re: Multiple DLL, multiple THREADS, multiple applications or something else?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|