At 09:34 AM 20/02/2009, you wrote:

>Hi there,
>
>I didn't see this previously asked anywhere: We want to use Firebird
>embedded in our application, which runs on both Windows and Mac OS X,
>but we would really like the firebird engine to run in a separate
>process - for both stability, memory usage, and thread contention
>issues (our app needs to keep as much out-of-process as possible).
>We want to use the embedded client for its ease of distributing, and
>the fact that these will be single-user databases.
>
>As I understand it, the embedded build on Windows runs the Super
>Server,

Correct

>and on the Mac, it runs Classic server;

Not correct. On Mac, it runs the embedded server. The name of this library is libfbembed.so on "regular Unix" but it probably has some other name on MacOSX. It is a different model from either Superserver or Classic.

>am I correct to
>assume that on Windows, the embedded firebird engine is running in
>the same process as the calling app,

Two processes running in shared IPC space

> but on the Mac, it's in a separate process?

One process, viz. one instance of libfbembed.so, comprising a client passing requests to the embedded server, which is effectively the client opening the database file directly. On ***x, embedded requires server-like authentication which, AFAIK, is also obtained by a direct connection if the application user is not root.

>And if that's the case, would it be straightforward to modify the Windows build to use the Classic server model?

No. Consider the two embedded implementations as distinct models that present with similar (though not identical) characteristics. The differences are due to differences in how the OS's implement inter-process communications, but neither is like Classic.

If you want a Windows stand-alone setup to behave like Classic, deploy the Classic server and use the local loopback server. If you want the deployment model to be equivalent, do the same on MacOSX. One is curious to understand why you think it's important, though. If you are planning to run your MacOSX client application as a Windows client under a wine server, the **x embedded server won't be available, anyway...

./heLen