Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Accessing component from thread

Status
Not open for further replies.

djjd47130

Programmer
Nov 1, 2010
480
US
I am building a Windows Service Application. In this service, I have to build a thread. I have a client socket component dropped into the service. This component must stay in its place, not created in the thread, because a majority of its purpose is running from within the service its self. However, I need to be able to send data through this socket from within this thread.

What would be the best approach? I'm thinking of building a single string buffer in this thread, then in the service, read this buffer and send along anything which may be in this buffer. It would be much easier though if I could directly access this component from within the thread execution. I'm thinking of adding a parameter to the thread's constructor to pass along a pointer to this component, like...

Code:
constructor TMyThread.Create(ASocket: TJDClientSocket);
begin
  //Assign ASocket to a variable within thread...
  fMySocket:= ASocket;
end;

Then, I should be able to access this component from within the thread by using fMySocket.

Right? or Wrong?

Any suggestions?


JD Solutions
 
Couldn't you create the component within the thread execution and use it there? Or am I missing something?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.
 
That was my first idea, but as I mentioned, a majority of this component will be used from the service's main thread - the additional thread only needs to use a fraction of this component.



JD Solutions
 
I'd probably still just create the component in the thread if it doesn't impact anything else.

If it helps, what seems to be the rule I go by in trying to devise the threads I've done (FWIW, most of the ideas work, it's just executing them that gets hard to wrap my mind around, along with knowing what is "best"), is thinking of the thread as an extra worker like in a human-oriented job. You make sure they each get their own tools and if they have to share you make sure it can be done, and then make sure they don't step on one another.

Again, practice seems to make perfect in about everything. I know I'll be expert on them eventually, and I'm sure you will too if you keep at it.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.
 
Thanks for the input. In some scenarios, with some components (let's say a TADOQuery component), it would be no problem to create a second instance from within the thread. Unfortunately, this relies on one single connection through the same port, if I create a second instance of this component in the thread, the server will recognize it as another connection. The server needs to receive the data from this socket as one single connection. So I can do with copying some pointer to this component (if possible). I'm afraid the proper way to do it is with the string buffer - but that will be quite difficult.

In general, how can I pass a pointer to an object from the main service thread to the additional thread? That's the main issue I need to solve. It only needs to do this once - when the thread is created. That's why I mentioned adding it as a parameter to the thread's constructor method, then saving that pointer within the thread.

I just need a sample - Google is sending me all over the place on the subject.

JD Solutions
 
In general, how can I pass a pointer to an object from the main service thread to the additional thread?

A component (or any object actually) is usually just a dynamically created object anyway, so passing it as you are will work, assuming there is nothing thread-unsafe about the main component. It's a pointer.

A dumb example, and yes TMemo is not thread-safe in general, but something that shows it works.

Code:
type
  TTest = class(TThread)
  private
    { Private declarations }
    fMemo: TMemo;
  public
    constructor Create(ASocket: TMemo);
  protected
    procedure Execute; override;
  end;
  TForm1 = class(TForm)
    Memo1: TMemo;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

implementation

constructor TTest.Create(ASocket: TMemo);
begin
  Inherited Create(true);
  fMemo := ASocket;
  FreeOnTerminate := true;
  Resume;
end;

procedure TTest.Execute;
var
  i: integer;
begin
  for i := 0 to (fMemo.Lines.Count - 1) do
    fMemo.Lines.Add('Test 2 ' + IntToStr(i));
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  TestThread: TTest;
  i: integer;
begin
  Memo1.Clear;
  for i := 0 to 19 do
    Memo1.Lines.Add('Test 1 '+ IntToStr(i));
  TestThread := TTest.Create(Memo1);
end;

end.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.
 
Fantastic, that answers my question. Except I just realized something which I didn't think of at first - this thread also needs to be able to receive data from this socket's OnRead event (which is already assigned in the main service). Nice to know I can pass that pointer, but I may wind up having to use a string buffer anyway.

Thanks for the help.


JD Solutions
 
this thread also needs to be able to receive data from this socket's OnRead event (which is already assigned in the main service). Nice to know I can pass that pointer, but I may wind up having to use a string buffer anyway.

You can shuffle around instances of "OnRead". When in the thread you can assign a thread version, when not, you can switch it back to the main version.

Again if you have both threads using the same object at the same time you'll have a problem. But it won't be a problem if only one thread uses the component at a time.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top