🚀 go-pugleaf

Paul wrote:

> I'm setting the socket type to nonblocking, is this the problem, should non 
> blocking components be used in threads? 

Yes. You cannot use nonblocking in a thread as that depend on events triggered
from a message queue. There is no such queue in your thread. But you could
add such a loop I think.

> And I'm passing NULL in the 
> constructor parameter for the component, does anyone know what this is used 
> for, 

As usual the -vcl-owner will delete that component when it is deleted
itself. If you pass NULL then your component should delete it in the
destructor. If you pass 'this' then it will be deleted automatically
provided that OwnerMbx is a vcl object.

>     if (AsServer)
>     {
>         // create TCP Server Socket, with default parameters
>     }
>     else
>     {
>         // create TCP Client Socket, with default parameters
>     }

Seeing that you make one class that can behave both like server
and client I shiver. I have done such things too but now my opinion
is that live is much easier having two classes. Maintainability
of code only for a server and only for a client is much easier then.

Hans.

> Yes. You cannot use nonblocking in a thread as that depend on events 
> triggered
> from a message queue. There is no such queue in your thread. But you could
> add such a loop I think.

Thought so, back to the drawing board!

> As usual the -vcl-owner will delete that component when it is deleted
> itself. If you pass NULL then your component should delete it in the
> destructor. If you pass 'this' then it will be deleted automatically
> provided that OwnerMbx is a vcl object.

I'm deleteing the object, so I will leave it at NULL for now.

> Seeing that you make one class that can behave both like server
> and client I shiver. I have done such things too but now my opinion
> is that live is much easier having two classes. Maintainability
> of code only for a server and only for a client is much easier then.

It seemed like a good idea at the time, but like you said, I'm not so sure 
its a good idea anymore.

Thanks for your input.

Paul 

"Hans Galema" <notused@notused.nl> wrote in message
news:433e6bce$1@newsgroups.borland.com...

> You cannot use nonblocking in a thread

Yes, you can.

> as that depend on events triggered from a message queue.

You can give the thread its own message queue.


Gambit

"Paul" <plmacca@clara.co.uk> wrote in message
news:433e524d$1@newsgroups.borland.com...

> I've written some classes to wrap the server and client components
> (and serial) to create some connectivity classes.

You might consider using a pre-written library that already does all of that
for you.  Indy (http://www.indyproject.org), for instance.  In particular,
due to Indy's plugin architecture, adding serial port support would take
minimal effort.


> But if I try to instantiate the class(es) in a thread, then only the
serial
> connectivity works.  The server and client socket fail (such as it never
> gets the events to show client connecting or connected).

Non-blocking notifications are message-based.  Thus your thread would need
its own message queue to dispatch the notifications properly.  If that does
not suit your needs, then you will have to use blocking sockets instead,
which means that you will not need a message queue at all, but you will
likely have to re-think your read/writing strategy a bit.


Gambit

>> You cannot use nonblocking in a thread
>
> Yes, you can.

Correct. IMO, the right sentence to write was "You SHOULD NOT 
use nonblocking sockets in a thread". It doesn't make much sense 
as we all stated many times in the past.

Steve. 

Remy Lebeau (TeamB) wrote:
>>You cannot use nonblocking in a thread
> 
> Yes, you can.
> 
>>as that depend on events triggered from a message queue.
> 
> You can give the thread its own message queue.

If you quote me then quote me in a reasonable way. I stated:

 >>> Yes. You cannot use nonblocking in a thread as that depend
 >>> on events triggered from a message queue. There is no such
 >>> queue in your thread. But you could add such a loop I think.

So I already gave the hint that it was probably possible if a
message queue was added.

You could have confirmed my suggestion instead of omitting it
and bringing the adding of a queue as your idea.

Hans.

"Paul" <plmacca@clara.co.uk> wrote in message
news:4342c2c8$1@newsgroups.borland.com...

> All of you have mentioned adding a message Q to the
> thread, where can I get info on this?

A message queue is nothing more than calling the Win32 API
Get/PeekMessage(), TranslateMessage() and DispatchMessage() functions in a
loop for the lifetime of the thread.  For example:

    void __fastcall TMyThread::Execute()
    {
        MSG msg;
        while( GetMessage(&msg, NULL, 0, 0) > 0 )
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }

    void __fastcall TMyThread::TerminateThread()
    {
        PostThreadMessage(ThreadID, WM_QUIT, 0, 0);
    }


Gambit

Thanks for all your input.

All of you have mentioned adding a message Q to the thread, where can I get 
info on this?

Thanks

Paul

PS. I will look at the indy project site also.


"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:4341ae16$3@newsgroups.borland.com...
>
> "Paul" <plmacca@clara.co.uk> wrote in message
> news:433e524d$1@newsgroups.borland.com...
>
>> I've written some classes to wrap the server and client components
>> (and serial) to create some connectivity classes.
>
> You might consider using a pre-written library that already does all of 
> that
> for you.  Indy (http://www.indyproject.org), for instance.  In particular,
> due to Indy's plugin architecture, adding serial port support would take
> minimal effort.
>
>
>> But if I try to instantiate the class(es) in a thread, then only the
> serial
>> connectivity works.  The server and client socket fail (such as it never
>> gets the events to show client connecting or connected).
>
> Non-blocking notifications are message-based.  Thus your thread would need
> its own message queue to dispatch the notifications properly.  If that 
> does
> not suit your needs, then you will have to use blocking sockets instead,
> which means that you will not need a message queue at all, but you will
> likely have to re-think your read/writing strategy a bit.
>
>
> Gambit
>
> 

that was quick. thanks

> A message queue is nothing more than calling the Win32 API
> Get/PeekMessage(), TranslateMessage() and DispatchMessage() functions in a
> loop for the lifetime of the thread.  For example: