• Welcome to SQLitening Support Forum.
 

News:

Welcome to the SQLitening support forums!

Main Menu

slRunProc in a Thread Function crashes app

Started by Bern Ertl, September 20, 2012, 05:23:19 PM

Previous topic - Next topic

Bern Ertl

I'm probably missing something obvious and fundamental, but I just tried creating a Thread Function for the sole purpose of calling a SQLitening Proc and it crashes my app when it tries to call slRunProc. 

My app establishes a connection and opens a database.  Then it creates a new dialog.  Previously, in the process of initializing the new dialog, it called slRunProc.  But this caused a noticable delay as the client app waited on the server to finish the processing of the slRunProc function.  So I tried creating a thread just to call slRunProc, but it ends up crashing the app.

Ideas?

Fred Meier

QuoteIdeas?
No, there is nothing in slRunProc, that I know of, that will prevent it from being used in a thread.  The below simple code works fine. 
You might try your complex proc in a simple program like this.


#Compile Exe
#Include "SQLitening.Inc"

Thread Function T1(byval rlParm as Long) as Long

   slRunProc "BEntry2", 0, 0, "", "", ""
   ?"Thread Done

End Function


Function PbMain()

   Local llA as Long

   slConnect
   thread create T1(0) to  llA
   ?"Main Done

End Function

Bern Ertl

I see now that each thread within an application must open a given database individually.  I thought threads worked like window callback functions, but they are apparently quite different.

Fred Meier

QuoteI see now that each thread within an application must open a given database individually.
Yes, each thread must have it's own database handle which is created in slOpen. There is
a way to inherit the database handle (see slOpen doc below) but I have done some testing
and found a bug when using across threads in remote mode, I will fix in next release. 
So for now don't try to inherit the database handle across threads in remote mode.
Quote3. All numeric database handle.  This is the formatted value returned
        from slGetHandle or is the first parm received in a database Proc.
        Using this in remote Procs allows for a database handle to be inherited
        by SQLitening.Dll.  A flag will be set so this inherited database
        handle can not be closed.

QuoteI thought threads worked like window callback functions, but they are apparently quite different.
I think of threads as a separate process sharing global variables but since SQLitening is thread-safe there are no global variables.
I think of a callback function as just a normal function that only windows can call.

Bern Ertl

Quote from: Fred Meier on September 21, 2012, 01:08:32 PM... There is
a way to inherit the database handle (see slOpen doc below) but I have done some testing
and found a bug when using across threads in remote mode, I will fix in next release. ...

Oh, that would be fantastic.  I wil be eagerly looking forward to the fix.

Fred Meier


Bern Ertl

Awesome.  Thanks Fred.  I will be testing it out shortly.

Bern Ertl

For clarification...THREAD FUNCTION MyThread( BYVAL hData AS DWORD) AS DWORD

   LOCAL pMyUDT AS MyUDT PTR

   pMyUDT = hData

   slOpen FORMAT$( @pMyUDT.hDB, 18)

...

END FUNCTION


@pMyUDT.hDB = slGetHandle() in the main application process/thread.

I do not need to use slClose in the thread function, correct?

Bern Ertl

If I'm in remote mode, can I close the connection in the thread function without closing the database?

Fred Meier

QuoteI do not need to use slClose in the thread function, correct?
Correct, inherited database handles will not close.  If you issues a slClose it will be ignored.
QuoteIf I'm in remote mode, can I close the connection in the thread function without closing the database?
Yes, all non inherited database handles are automatically closed when your program ends, a thread ends, or if running in remote mode, when you disconnect in the process or thread.   If you are done with a database but your program will continue to run for some time then it is a good idea to close it with slClose. 

Bern Ertl

SQLitening appears to be working fine with database handles shared across threads.  Because threaded functions require a new connection to the database (in remote mode), I have to re-register custom functions for SQLite and my SQLiteningProcX functions that are using variables with threaded scope have to re-initialize data structures for each thread/connection. 

In the end, it appears that my server side calculations in the SQLiteningProcX.DLL isn't the bottleneck that I thought it was.  Back to the drawing board for me.