Prev: GNAT.Sockets, Create_Selector and error 10055 on Windows
Next: gnat project "include file"
From: Maciej Sobczak on 6 Dec 2009 15:49
On 6 Gru, 14:06, Tomek Walkuski <tomek.walku...(a)gmail.com> wrote:

> MySQL docs say:
>
> "In a nonmulti-threaded environment, the call to mysql_library_init()
> may be omitted, because mysql_init()  will invoke it automatically as
> necessary. However, mysql_library_init() is not thread-safe in a multi-
> threaded environment, and thus neither is mysql_init(), which calls
> mysql_library_init(). You must either call mysql_library_init()  prior
> to spawning any threads, or else use a mutex to protect the call,
> whether you invoke mysql_library_init() or indirectly via mysql_init
> (). This should be done prior to any other client library call."
>
> So in multi-threaded environment mysql_library_init CANNOT be ommited.

Of course it can, and even the docs that you cite above tells you
under what conditions it can be done.
If you plan to use *that* function from multiple threads, you have to
protect it with a mutex. It is dead obvious that you might also ensure
by other means that there is only one thread that calls this function
and if you do ensure that, everything is OK - even if later on you
will have many threads creating the actual connections and interacting
with the database.

Don't be mislead by this "multi-threaded environment" horror. Every
single program that is in principle "multi-threaded" has or can be
restructured to have some initialization phase when it is purely
single-threaded and this is a perfect place to put initialization
calls that are not themselves thread-safe.

Coming back to MySQL and database clients in general - I would be
surprised to see a program that lazily "initializes" the database
environment in the context that is already multi-threaded. This part
of documentation probably reflects the most frequent use-case for
MySQL, which is in web applications implemented in terms of reactive
"scripts" (think about PHP): indeed, there is no explicit
initialization phase and potentially any action might trigger the
initialization calls.
But if you write in Ada you can do better (even with AWS).

> And how about mysql_library_end() ? I could not import it to Ada and
> this function performs some memory clean up after disconnection.

I think that the world will not end tomorrow if you "forget" to call
it.
Think about programs that never finish and/or that use the database
all the time - these programs, well, don't call it.

And really - what is exactly your problem with importing these two
functions?
Let me guess - they are *macros*. What a mess...

(checking the mysql.h header ... yes, they are macros)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada
From: Tomek Walkuski on 6 Dec 2009 16:13
On 6 Gru, 21:49, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote:
> And really - what is exactly your problem with importing these two
> functions?
> Let me guess - they are *macros*. What a mess...
>
> (checking the mysql.h header ... yes, they are macros)
>

Thank you for your answer.

My question was not about: is it good or bad to call these functions?
I wanted to know why I can't import them.
From: Stephen Leake on 7 Dec 2009 01:55
Tomek Walkuski <tomek.walkuski(a)gmail.com> writes:

> On 6 Gru, 16:59, Stephen Leake <stephen_le...(a)stephe-leake.org> wrote:
>> Are you building GNADE from scratch? It contains many imports similar
>> to yours, so it's hard to see why yours would fail but those succeed.
>>
> I have prepared small program only for testing purposes. I have tried
> to import only these two functions.

Ok.

A good alternative is to use the GNADE ODBC interface; there are ODBC
interfaces to MySQL on both Linux and Windows.

--
-- Stephe
First  |  Prev  | 
Pages: 1 2
Prev: GNAT.Sockets, Create_Selector and error 10055 on Windows
Next: gnat project "include file"