Sockets and threads

[killerbot]

Here's another question :

I have a thread (detached thread) which will create a socket connection, send a request and wait for the answer.
Once the answer arrives, it is processed. In case the answer does not arrive in time, we will no longer wait on it.

That means that the Entry() function of the thread (which created the thread and waited for some time (semaphore with timeout) will run till the end. One of the last steps in the thread entry function is to call Destroy() on the socket

Something like this :

Code: Select all

Entry()
{
  // create socket 'MySocket'
  // do some stuff
  MySocket->Destroy();
}

The Destroy method will make sure no more data will come in on the socket, however the socket itself will be deleted when all pending (socket) events are processed [it will be deleted at idle time].

However after the Destroy() the thread can finish, and will be automatically freed/deleted by wx, but what if after that deletion one of those pending socket events is processed. But it's handler (the thread) no longer exists.

Is there a way, to know/wait when all events of that Socket are processed, and only then allow the thread to finish ??

[radcapricorn]

Actually the socket's Destroy() method calls Notify(false) thus suppressing notifying the handler. I've seen the complains about some troubles related to the order of deletion of socket/handler but I suspect the reason for them is something different than event occurring after Destroy() call.

[killerbot]

Yes, and Destroy() will also call Close(), but there may be some events (data already came in on the socket) in the event queue waiting to be processed. So after the Destory() no new data will come in, and as such no new socket events will be added to the event queue. But what with those that might be in the queue.

The will want to be handled by their event handler, which is on the verge of to be deleted (threads has finished). Notify(false) will just result in the same, that no new events will be created (it disables socket events), but I don't think it will remove the pending events.

From the documentation of Destroy() and Close() :

Although Close immediately disables events for the socket, it is possible that event messages may be waiting in the application's event queue. The application must therefore be prepared to handle socket event messages even after calling Close.

Destroys the socket safely. Use this function instead of the delete operator, since otherwise socket events could reach the application even after the socket has been destroyed. To prevent this problem, this function appends the wxSocket to a list of object to be deleted on idle time, after all events have been processed. For the same reason, you should avoid creating socket objects in the stack.

Destroy calls Close automatically.

[/code]

[doublemax]

if you use sockets in a thread, then you should use blocking mode and not use events. Threads can only send events, they can never receive events.

[killerbot]

My thread object is the result of multiple inheritance : from wxEventHandler and from wxThread.
And I have events coming in, in my thread objects of that type.

I think this is normal behavior, no ?

[doublemax]

http://docs.wxwidgets.org/stable/wx_wxt ... adoverview

last paragraph

[killerbot]

that's bad news. So strange it works on my systems (have several apps doing this), though in some case I have crashes (event handler and mutex locks issues in the callstack dump).

So say I want to query some ip addressable devices. I can do it in threads, but I have to use the Blocking Wait until there's connection.

And then I need to poll in a loop to see if data is coming in (say the device might send several messages, and only one of those messages is the answer I expect) ?

That sounds very inefficient or is there something I am overlooking ?

[doublemax]

i think the nice thing about sockets in secondary threads is that you *can* use blocking calls, because it makes the code much simpler and easier to follow.

I don't see it as a problem that you *have to* use blocking calls, it would never occur to me to use events when using threads.

Try reading the chapter about sockets in the wxWidgets book:
http://www.informit.com/content/images/ ... 6_book.pdf

Maybe it shines some light on the issue.