Re: More client server problems
From: Martin James (mjames_falcon_at_dial.pipex.com)
Date: 01/08/04
- Next message: Nicholas Sherlock: "Re: PriorityQueue equivalent for delphi??"
- Previous message: Jeremy Collins: "Re: is it possible to create integer-variables with the standard value 0??"
- In reply to: Pawel: "Re: More client server problems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 8 Jan 2004 21:08:18 -0000
"Pawel" <thejaffe21@hotmail.com> wrote in message
news:3ffda434$1@newsgroups.borland.com...
> In java i would just set up blocking streams. so all i would haveto do is
> call a read from the client side that would block waiting for the server
to
> write to the stream.. this does not sound like a good method but you can
> also set a timeout on the block and then handle the error if it does time
> out..
I may have got hold of the wrong idea here. When you talk about
client/server comms, do you mean
a) Transferring objects/records, ie pointers, between 'worker' threads and
the main thread, or between threads in general, using a mailbox-type system?
Delphi does not have a producer/consumer mailbox, as such. Windows has
message queues, which have the limitation that only one consumer is allowed
to wait. Thre are APIs to send tokens/pointers/objects between threads
using these queues. Windows/Delphi has a message-handler mechanism that can
fire events in the main thread, triggered by messages posted from worker
threads, either on a queued basis or one-off non-queued. At least, they are
available in Win32.
b) Transferring octet streams between TCP clients and servers?
This is fairly easy with the many TCP component sets available, at least, it
is in Win32. Indy, as alrady mentioned by Harley, does this well.
> i think my main problem here is using delphi's event model..
..and my main problem is understanding your main problem :)
> right now my main idea is to create a thread that has an event handler in
it
> so it can update a variable in my class so that the loop can read it and
> return it to the main program..
>
> i just need a way to block and wait for a result instead using the event
> model.. i need to wait for that result anyways.??
In the main thread? No, you don't, honest. Why do you need to wait for the
result in an event handler? Why can you not exit the event handler & get
the result later *in another event* fired by a message containing the
result? Any state info or other data that is around in the initiating
event handler can be sent to the worker thread in the work request &
returned in the message-hadler event, so that the data from the server can
be processed easily in the 'result' event. So you have a class. like say:
TcommsObject=class(Tobject)
public
data:integer;
moreData:string;
evenMoreData:real;
counter:integer;
index:integer;
lineNumber:integer;
displayHere:Tmemo;
serverRequest:string;
serverReply:string;
end;
You create one, fill it up with stuff, post it to the worker thread and
*exit the event handler*. The work thread gets the object and does
whatever it does to communicate with the server in a blocking manner & get a
reply, stuffing it into the 'serverReply' field. When the serverReply is
in, the work thread posts the object back to the amin thread, where it fires
an event. In this event, the main thread has all it needs to process the
server reply - it's all in the object.
Two threads - no looping!
Rgds,
Martin
- Next message: Nicholas Sherlock: "Re: PriorityQueue equivalent for delphi??"
- Previous message: Jeremy Collins: "Re: is it possible to create integer-variables with the standard value 0??"
- In reply to: Pawel: "Re: More client server problems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
