gdpicture, threading issues

[mattewan]

Hello,

We have recently bought the document imaging sdk and we are trying to incoporate it in one of out multithreaded applications to do image processing.

here is a snippet of code that is executed within a threaded procedure:

Code: Select all

    Private Sub ThreadLoadFiles()
        Dim Imaging as New GdPicture.GdPictureImaging
        Dim ImageID As Integer = 0
        Dim PageCount As Integer = 0
        Imaging.SetLicenseNumber("xxxxxxxxxxxxxxxxxxx")

        For Each oneitem as string In filelist
            ImageID = Imaging.CreateGdPictureImageFromFile(oneitem)
            If ImageID <> 0 Then
                'do some image processing
            End If
        Next
    end sub

this code executes fine while running one thread at once, but when we execute more than one thread we get random errors on the line which executes CreateGdPictureFromFile()

here are some of the errors we get:
A first chance exception of type 'System.IndexOutOfRangeException' occurred in GdPicture.NET.dll
A first chance exception of type 'System.NullReferenceException' occurred in GdPicture.NET.dll

When we get a nullregerenceexception .... if we re-execute the same line it usually works.

Is there something i am missing here?

Thank you

[mattewan]

On a side note, i just tried threading the OCR.

Running one thread at a time is fine, however, launching more than one thread compeltly kills the application with no exception raised.

However, if i run multiple instances of the application then i can ocr on 4 cores in a pc, using 4 seperate applications.

To me this seems like gdpicture is not threadsafe. Is there any chance it will be in the future..... as we intent to use this mainly for batch processing and really want to take advantage of multiple processors & cores.

[Loïc]

Hi,

Are you using the last release ?

We made some improvements for multi thread problems.

If you are able to reproduce the error in a demo application we will be happy to help you to fix your issue.

Kind regards,

Loïc

[mattewan]

I am using the release from 30th March.

I will create a sample project tonight and attach it here (with the product keys ommited)

Thank you.

[mattewan]

Right i am attaching a sample project i knocked together really quickly to demonstrate crashing while running multiple threads.

The program takes a source path (i have been using a folder full of tiff files - single page), a dest path (which i set to the same path as the source), and thats it.

There is a drop down to choose between 1 - 4 threads, as you will see 1 thread seems to execute fine, however, if you execute more than one thread at gdpicture seems to show message boxes with errors. Yesterday it was just making my app quit, not sure whats changed.

This is using OCR, however, basic tasks like loading image files seem to fail also.

I have removed my license keys from this program - they are set in clsWorkerThread::ProcessBatch()

Thank you.

[mattewan]

Hello,

Just wondering whether there has been any developments on this

Thank you.

Matthew Jones

[Loïc]

Hi Matthew,


First, sorry for the delay. Second, thanks a lot for your sample. It helps us a lot.

We found the origin of the problem: a common data structure in the toolkit core. However, we need a lot of time to rewrite this part. So I think the toolkits will be 100 % thread safe within 3 months

Again, thank you for your sample.

Kind regards,

Loïc

[mattewan]

Hello Loic,

Thanks for the reply.

I had a feeling it wasn't going to be something too easy to fix, and completly understand that it may take a while to repair.

I just needed to know whether it was going to be something that was fixed in the future, because if it is, then i will carry on writting my software threaded, but just limiting the application to only launching one thread until the toolkit is fixed.

Thanks for investigating this.

Matthew Jones

[mattewan]

Hello Loic,

I know it hasn't quite been 3 months yet, but im just checking to see if there has been any progress made on this, or whether its going to be quite a while before we see something.

Thank you.

Matthew Jones