Very Computer

I am writing an open server gateway and I'm having difficulty getting it to
process multiple queries at the same time. I think I need my language
handler to be able to accept a request then spawn another process to handle
that request but the hassle is that the client gets an error of 'final DONE
not sent' when the original language handler terminates...

Has anyone out there written something similar?
Am I missing something really obvious here?

Please, anyone with any suggestions please help!

thanx
Malcolm

It sounds like your problem is that the routines you are calling are "blocking"
the Open Server.  (That's why you can't handle more than one request at once.)
If there is not a non-blocking (or asynchronous) version of the routines you
are calling, your Open Server will have to spawn an additional OS process
(asynchronously).  The OS process can call your routines, and the Open Server
just needs to check for when the process completes.

The thread that is serving the client needs to stay running until everything is
done and the results have been passed back to the client.

-Chris

Thanks for your help.
Just a few more questions if you do not mind:
I figured as much but as a test, I coded the routine that processes queries
loop, and inside the loop I sleep and call srv_yield(). I thought that this
would at least allow another request to get put onto my queue but it just
hangs the entire open server. Are you suggesting that the routine to process
requests spawns a service thread?
I know I may be pushing things here, but would you happen to have any sample
code?

thanx and regards
Malcolm

My experience is with openServer on Solaris.  Since the openServer runs as a
single
process, invoking any Unix function that blocks (such as sleep, select)
freeze the
process and hence the openServer.  Like Chris said, you need to look at
asynchronous
versions of unix calls (in my case, it was polling for sun rpc's instead of
blocking until receipt).
Sybase does give you some functions like srv_sleep to get around these
problems.  ctlib
calls also work threaded so you can have multiple threads accessing a
database at the same
time.

A service thread is a sybase pseudo thread (at least on my Solaris version),
it doesn't result in another schedulable unix process.

How to get around this problem depends on what you are trying to do.

Dave

:>Hi Chris
:>
:>Thanks for your help.
:>Just a few more questions if you do not mind:
:>I figured as much but as a test, I coded the routine that processes queries
:>loop, and inside the loop I sleep and call srv_yield(). I thought that this
:>would at least allow another request to get put onto my queue but it just
:>hangs the entire open server. Are you suggesting that the routine to
: process
:>requests spawns a service thread?
:>I know I may be pushing things here, but would you happen to have any
: sample
:>code?
:>

: Malcolm,

: My experience is with openServer on Solaris.  Since the openServer runs
: as a single process, invoking any Unix function that blocks (such as
: sleep, select) freeze the process and hence the openServer.  Like
: Chris said, you need to look at asynchronous versions of unix calls
: (in my case, it was polling for sun rpc's instead of blocking until
: receipt).

Yes, if you are working with file descriptors there is srv_select()
or srv_poll() which allows you to block on a group of descriptors
in an Open Server friendly manner (i.e. context switches still occur).

: Sybase does give you some functions like srv_sleep to get around these
: problems.  ctlib calls also work threaded so you can have multiple
: threads accessing a database at the same time.

Yup.  ct-library and, to some extend, db-library are Open Server
friendly as well, so they are safe to call without blocking the
whole server.

: A service thread is a sybase pseudo thread (at least on my Solaris
: version), it doesn't result in another schedulable unix process.

FYI, with Jaguar CTS 3.0 (a.k.a Enterprise Application Server 3.0,
a.k.a. EAS 3.0), Sybase added the ability to, with a few modifications,
load an existing Open Server into the context of the EA Server,
where it will utilize the EA Server Open Server libraries.  These
libraries use real preemptive operating system threads.  The downside
is, of course, that you will need to make sure that your Open Server
is preemptive thread-safe...I haven't seen too many that were.

The upside is that all of your blocking issues go away.  I have
ported a rather large Open Server to EA Server, and it isn't
terribly difficult.

-scott

--

       http://www.voicenet.com/~gray/sqsh.html