Home/ Questions/Q 498951
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T05:56:09+00:00

I’m currently designing an assembly that will be used by third parties. One of

  • 0

I’m currently designing an assembly that will be used by third parties. One of the classes has a long process of TCP connections and it informs about its process using events. For example

''# Do stuff that takes some time
RaiseEvent CompletedFirstPartEvent()
''# Do stuff that takes some time
RaiseEvent CompletedSecondPartEvent()
''# Do stuff that takes some time
RaiseEvent CompletedSecondPartEvent()

What I’ve seen if that if the handler of one of those events takes too long (or even worse, it blocks) I can have timeouts and it’s hard for the developer to see that one class is not working fine because his handler is taking too long.

I was going to fire the events in a new Thread to avoid this issue but this looks strange to me because I’ve never seen something like that, what I’ve seen until now is the developer spawning a new Thread if his handler was going to be timeconsuming. So the question is:

What would you do? Create a new thread or force the user to create his own thread? (Or is -there a better approach that I don’t know?)

Thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve got a Collector class that opens a “raw” socket and collects data from the local network. Internal to the Collector class, the socket reads are done by a Receiver thread. This thread fires an InternalPacketReceived event for each packet that is read from the network. Also internal to the Collector class, I also have a Distributor thread that subscribes to the Receiver’s InternalPacketReceived event. Packets received by the Distributor’s handler are added to an internal packet queue. The Distributor thread is then responsible for making the packets in the queue available to subscribers of the Collector’s public PacketReceived event. In this way, if the Distributor thread is stalled by a long-running handler, the Receiver continues to read packets without delay.

    From the user’s perspective, he’s interacting with a public interface on the Collector class – Start(), Stop(), subscribe to PacketReceived event, etc. Behind the scenes, the Collector is using two threads – Receiver and Distributor – to avoid the problem introduced by long-running handlers.

    I hope that’s clear.

    • 0