Re: There is no consensus on beos yet...

[Daniel Berlin <dberlin at cygnus dot com>]

On Thu, 16 Nov 2000, Bruce Korb wrote:

> Daniel Berlin wrote:
> > When fixincludes *does* run (IE after killing the right processes, etc
> > necessary to make it go all the way through), it makes more changes than it
> > used to, on the same headers. Those changes cause the headers to no longer work
> > properly.
> 
> *which* headers are broken?  what breaks?  With well over 100 hacks
> in the hack definition list, it is not helpful to just know that
> one or more are wrong.  Which ones are wrong?  If you don't know
> that, then what changes cause the problems?  Then I can figure out
> what the cause of the problem.

I can't remember anymore, because I haven't run it in about a month 
(until today, when i just emailed jeff). As soon as i have fixincl 
*running* without crashing or hanging, i'll happily sort this part out 
myself and submit patches.

> > RE: the processes to kill.  Which processes are you  killing? > 
fixincl subprocesses?  A server shell?  A sed chain?  What?
> You keep asserting that it is broken, yet I still do not know
> what it is that is not working.

In my message to jeff a second ago, i emailed a detailed explanation of 
which proceses are being killed, why, etc.
> 
> > I already did, it crashes multiple times, hangs, etc.
> > It requires killing shell processes off (the right ones) to restart it,
> > etc.
> > 
> > If you think i'm exaggerating, try it.
> 
> OK.  Please send me a copy of BeOS :-).  I'm an OS junkie anyway.
ftp.be.com/pub/beos

Grab the readme, and follow directions.
You'll need the devtools too, from that dir.
If it's easier, you can telnet into my system, i have all the tools you 
need set up.


> 
> > BeOS is not posixy/unix enough to run fixincludes anymore (It used to
> > work, and does work with the branch the current released beos compiler is
> > based on.
> 
> *WHICH* one is that?  The shell script?  (please say, "No" here :)
Yup, we used the shell scripts because fast-fixincludes (as it was called 
then) didn't work on BeOS
>


> What behavior might that be?  As far as I  know, it expects to be able
> to write on one end of a pipe and have another process read from the
> opposite end.  I hope BeOS follows that model  ;-).

fork doesn't work all that well on BeOS, and you expect to be able to 
fork, then duplicate the file descriptors using fcntl so you can make stdin, 
stdout.

Nobody on beos uses fork (literally), because it doesn't mix with threads.
fcntl is also not up to snuff, because, once again, nobody uses fcntl on 
BeOS.
Nobody uses the posix api stuff unless they are porting unixy apps. 

It's not the actual piing, which works fine on BeOS, it's the way you are 
trying to set up those pipes, using fcntl, and forking, which appears to 
be causing hell.

My best guess is that the hang is caused by not being able to dupe the FD 
through fcntl, and thus, the shell process sittings waiting to read from 
a pipe that isn't giving it any input.


 > 
> > If you want to tell me it's not broken on BeOS, feel free to try
> > bootstrapping on a beos system, and see how long it takes you to figure
> > out which shell proceses you need to kill to make it keep going.
> 
> I am sure it is broken on BeOS.  But I cannot bootstrap it without a copy.
> Downloading a gazillion megabytes doesn't work very well over a < 56KB link.
> 
As I said, i'm happy to provide a computer you can see it on, and attempt 
to debug.