Re: Unix multithreaded program using Pro*C

Well, i just want to let you know that i found the problem (might come in handy when using dejanews). I did not do a "pmake clean" yet, which caused some files to be there which shouldnt. So after a "pmake clean" i got a runtime error, saying something like: Cannot use pthread with libaio_raw, link with libaio. This helped, i found that there is a bug in these libraries and digital had a patch for it. After installing the patch it all worked immidiately. As for the shared memory, i did state i used a class with static members as shared memory ( using new to allocate, so on the heap ), but recently i changed it to a "singleton", which works fine.

thank for the reactions, Jeroen

"Nuno Souto" <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message news:3b011672.6007485_at_news-server...
> On Mon, 14 May 2001 22:35:18 +0200, "Jeroen" <jeroenthuis_at_gmx.net>
> wrote:
> >Currently i am developing a (multithreaded) program in C++ which uses
 Pro*C.
> >snip
> >I also created some Pro*C code using statements as SQL ENABLE THREADS and
> >use contexes, but it doesnt help, which i guessed because there is only
 one
> >thread accessing the database. I compile and link using multithreaded
> >libraries. Does anybody have a clue of what is going on here ?
>
>
> In addition to Eric's comments, I'd add this as an idea.
>
> Since you have a single thread accessing the database, why are you
> using the ORACLE multi-threaded libs? Those are for use when you have
> multiple threads accessing ORACLE simultaneously. Since yours is a
> multi-thread but only one thread accesses the database, you can just
> use normal PRO*C calls and libs and do away with all the complexity of
> multi-threaded PRO*C.
>
> As for blocking calls, I thought the latest versions of PRO*C allowed
> for non-blocking. If I'm wrong, I know for sure OCI does allow
> non-blocking calls. Maybe that could be a better choice? AFAIK, OCI
> is available in both UNIX and NT, so portability wouldn't be an issue?
> But even OCI won't allow for simultaneous command execution, is that
> what you call non-blocking?
>
> Also: depending on the flavour of UNIX, multi-threading may be
> achieved in the same address space. Which means you can do away
> entirely with shared memory and just use a global heap to pass your
> SQL command strings. Much less stuff to go wrong and it would still
> work in NT as well.
>
> Just a few ideas, sorry I can't be more specific.
>
> Cheers
> Nuno Souto
> nsouto_at_bigpond.net.au.nospam
> http://www.users.bigpond.net.au/the_Den/index.html
Received on Sat May 19 2001 - 16:22:30 CDT