[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> 
> 	* I've progess a bit with MyCancelKey and MyProcPort (postmaster 
> send all that information to the backend with a BeOS kernel port : 
> nothing is visible on the command line except the port number but datas 
> don't stays in the port more than a few milliseconds). All Shared 
> memory segment are also restored in the backend process. But now, I 
> have a crash in SpinAcquire(OidGenLockId). It seems that SLockArray is 
> not initialized. Do I need to send it to the backend ?

Yes, I think I made some changes where initialization was done only once
in the postmaster, and inherited by every fork'ed backend.
-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 19 Jun 1999 08:08:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] BeOS port

	* I've progess a bit with MyCancelKey and MyProcPort (postmaster 
send all that information to the backend with a BeOS kernel port : 
nothing is visible on the command line except the port number but datas 
don't stays in the port more than a few milliseconds). All Shared 
memory segment are also restored in the backend process. But now, I 
have a crash in SpinAcquire(OidGenLockId). It seems that SLockArray is 
not initialized. Do I need to send it to the backend ?

	* BeOS provide a nice implementation of threads (But it's not posix 
threads). It could be interesting to adapt postgres to works with 
threads but there will be some work whith global variables (which will 
be shared by all backends in this case), they should be transfered in 
some kind of thread local storage. Is it somethong interesting to do ?

	* The Be guy try to improve there posix support but the case of the 
fork seem to cause some technical problems and the possible actions 
between a fork and an exec are pretty limited.


		cyril

>> I've already tried to put the exec back. But then I hit a problem 
with 
>> "MyProcPort" which is not initialised in the backend and make the 
>> backend crash. I've also found that "MyCancelKey" is set in 
postmaster. 
>> Are there any others ? 
>> 
>> Regarding the old code (6.3.2), there have been a lot of change in 
>> DoBackend/DoExec. I really need some expert advice on what to do.
>> 
>

>He's right though: there have been subsequent changes that depend on
>not doing an exec().  Offhand I only recall MyCancelKey --- that is 
set
>in the postmaster process just before fork(), and the backend simply
>assumes that it's got the right value.
>
>The straightforward solution (invent another backend command line 
switch
>to pass the cancel key) would not be a very good idea, since that 
would
>expose the cancel key to prying eyes.
>
>If BeOS does not have the ability to support fork without exec, does 
it
>have some other way of achieving the same result?  Threads maybe?
>(But Postgres is hardly the only common daemon that uses fork without
>exec; sendmail comes to mind, for example.  So it seems like the real
>answer is to beat up the BeOS folks about fixing their inadequate Unix
>support...)
>
>			regards, tom lane
>


>I recommend you get anonymous cvs access(see cvs faq on web site) do a
>log to show changes to postgres.c and postmaster.c, and you will find
>the exec was removed in one or two big patches.  Then do a cvs diff 
and
>see the changes made, and try and merge them into the current code 
with
>ifdef's.
>
>-- 
>  Bruce Momjian                        |  http://www.op.net/~candle
>  maillist@candle.pha.pa.us            |  (610) 853-3000
>  +  If your life is a hard drive,     |  830 Blythe Avenue

Sat, 19 Jun 1999 13:32:26 CEST
"Cyril VELTER" <cyril@mail.micronet.fr>
Re: [HACKERS] BeOS port