threads in thread pool may be blocked by this library

[Spring-grow]

Thank you for your creative work, it's really great!

When I read the source code, I found that when SampleGrabberCallback uses the system thread pool for processing, all available threads in the thread pool (other threads not actually used by the library) will be blocked by BufferedEvent, and other modules using the system thread pool in the same application will be restricted. As a library that may be referenced by many programs, I think this approach should be avoided in design. It may be better to use a thread that implements a simple event queue to do this. if my understanding of this program is correct?

            public SampleGrabberCallback(DirectShow.ISampleGrabber grabber, int width, int height, int stride, bool useCache)
            {
                this.BmpBuilder = new BitmapBuilder(width, height, stride, useCache);

                // create Buffered.Invoke thread.
                System.Threading.ThreadPool.QueueUserWorkItem(x =>
                {
                    while (true)
                    {
                        BufferedEvent.WaitOne(); // wait event.
                        Buffered?.Invoke(GetBitmap()); // fire!
                    }
                });

                grabber.SetCallback(this, 1); // WhichMethodToCallback = BufferCB
            }

[secile]

Hello, thank you for advice me important information. Before I fix it, I have to understand the mechanism of Thread and ThreadPool. I will investigate, Thank you.

[secile]

hello @Spring-grow Could you teach me. Is it Okey if I replace QueueUserWorkItem to 'new thread'?

public SampleGrabberCallback(DirectShow.ISampleGrabber grabber, int width, int height, int stride, bool useCache)
{
    this.BmpBuilder = new BitmapBuilder(width, height, stride, useCache);

    // create Buffered.Invoke thread.
    BufferedEvent = new System.Threading.AutoResetEvent(false);
    var thread = new System.Threading.Thread(x =>
    {
        while (true)
        {
            BufferedEvent.WaitOne(); // wait event.
            Buffered?.Invoke(GetBitmap()); // fire!
        }
    });
    thread.IsBackground = true;
    thread.Start();

    /*System.Threading.ThreadPool.QueueUserWorkItem(x =>
    {
        while (true)
        {
            BufferedEvent.WaitOne(); // wait event.
            Buffered?.Invoke(GetBitmap()); // fire!
        }
    });*/

    grabber.SetCallback(this, 1); // WhichMethodToCallback = BufferCB
}

[ARM830]

Here's the current situation: In WPF, I've initiated a camera and started capturing video. When the code for closing the camera is executed, the locations where the BufferedEvent.WaitOne() method is used might get blocked directly. In other words, after notifying the camera to shut down, the BufferCB() method is not invoked. The line if (Buffered != null) BufferedEvent.Set(); is not being used, which results in the BufferedEvent.WaitOne() method being continuously blocked. Therefore, when using Thread or ThreadPool, it is crucial to ensure that the thread generating the bitmap is closed first. This is my preliminary understanding. I am currently writing the code and preparing to verify my hypothesis.

[secile]

I decided to use new Thread instead of ThreadPool.

I noteced that Task.Run() method has TaskCreationOptions.LongRunning flag, and if this flag is setted, Task do not use ThreadPool, but use new Thread. This means long running thread should not use ThreadPool, but use new Thread.

This time I applied this idea.