Worker proper cleanup

[Adhara]

Hi,

two quick questions on how to properly dispose a worker instance. I could not find any documentations about.

• Should I also deregister the MessageReceived event when stopping a worker using the -= operator? If yes, should I do that before or after calling Stop()?
• Should I explicitely call Finalize() after stopping a worker?

A last question on the MessageReceived event handler: is the sender parameter set? What does it reference?

Thanks a lot
Regards
A

[K.Wagner]

Hello,

All these question have actually not to do with the Worker class directly but with general C# programming.

Should I also deregister the MessageReceived event when stopping a worker using the -= operator?

This depends on how your code looks like, but in most cases the answer is "yes, you should". Note that mantaining any reference to an object prevents the GC from deleting it. C# will keep alive the Worker object until you remove the refereneces to it (e.g. the object implementing the event handler), or terminate the program. You find more information on this in the Microsoft programming guide, Unsibscribing Events. In these scenarios it is safe not to deregister an event:

1. When subscriber (any class) and publisher (Worker) have the same lifetime.
2. If you only have one Worker object and this is intended to be available the whole program execution life.

If yes, should I do that before or after calling Stop()?

It's doesn't matter if you do this before or after calling the Stop() method. Events that have no subscribers are just never raised. See the Microsoft programming guide, Events overview.

Should I explicitely call Finalize() after stopping a worker?

No, the GC takes care of calling Finalize() when the object is qualified to be garbage collected. See the Microsoft programming guide, Finalizers.

is the sender parameter set? What does it reference?

The sender parameter of an event denotes the object rising the event. This is in general the publisher itself, in this case the Worker object generating the event. See the Microsoft programming guide, Handle and rise events.

[Adhara]

Thanks for the free C# lesson.
Finalizers are not very common in .NET, Worker should probably implement IDisposable, if it needs to release managed resources. (as suggested here by Microsoft), this would also allow using statement and make Worker lifecyle more obvious.

To avoid event registration/deregistration issues it would be nice to register a callback not an event handler, the callback could then be called passing directly the queue. This is important because at the time being when the event handler is called there is a threading issue on the worker object itself, since I am requested to call the dequeue method on it. I would at least make it obvious from the doc that the sender is actually the worker itself, so using it inside the event handler should be safer.

Thanks, Regards
A

[K.Wagner]

Thanks for the free C# lesson.

You're welcome.

Finalizers are not very common in .NET, Worker should probably implement IDisposable, if it needs to release managed resources.

Actually, they are. You just do not see them. The finalizer is first implemented by the class object, and all other classes derived from it. I think you misunderstand something: IDisposable is mainly used for releasing "unmanaged" resources (not managed). The Worker class uses no unmanaged resources (like pointers to files or such things). The event mechanism is done in a managed way.

from learn.microsoft.com

IDsposable.PNG (11.98 KiB) Viewed 1670 times

from learn.microsoft.com

Finalizer.PNG (31.49 KiB) Viewed 1670 times

this would also allow using statement and make Worker lifecyle more obvious.

Yes, implementing IDispose would allows writing an "using" statement with the Worker objct. Though, the the Worker class was not designed with this purpose. It is rather designed to be used for a large period of time (normally as long as the applcation itself), to help users writing apps like the PCAN-View. It makes no sense to have a class like the Worker in a using statement, just for send or receive a couple of messages. For this purpose, you can easily use the class Peak.Can.Basic.Api, and either write your own worker or directly call the API functions.

To avoid event registration/deregistration issues it would be nice to register a callback not an event handler, the callback could then be called passing directly the queue.

A callback is more suitable for having single indications (like when a time consuming process ends). It is also a design question. Is like asking to have a Callback instead of the Elapsed-Event within the class System.Timers.Timer. Note also that the MessageAvailable event tells you the index of the queue you need to poll.

This is important because at the time being when the event handler is called there is a threading issue on the worker object itself, since I am requested to call the dequeue method on it.

Not sure to understand. This is not an issue, but a normal process. Reading is done in another thread. This is also mentioned in the help:

from docs.peak-system.com

Synch.PNG (32.24 KiB) Viewed 1670 times

I would at least make it obvious from the doc that the sender is actually the worker itself, so using it inside the event handler should be safer.

"it is obvious" --> Sorry, but as I wrote before, this is the normal way this is programmed using C#.

We appreciate the opinions and suggestions from our customers. Even when we think that the Worker class already saves you a lot of work, it is easy to use and to understand, we will check if we can enhance it to be even more comfortable. Do not hesitate to post any idea or improvement suggestion you may have (you can also use the forum Suggestion and Feature Requests). We cannot promise to implement these, but we will check if we can.

As the actual questions are answered I am closing this post. Feel free to open a new one if you have further questions.