Subject: Re: Curious behavior of CYGSERVER
From: "David A. Cobb" <[email-masked]>
To: Conrad Scott <[email-masked]>, Cygwin Discussion <[email-masked]>
Date: Sun, 15 Sep 2002 18:41:17 -0400

Conrad Scott wrote:

>"David A. Cobb" <[email-masked]> wrote:
>  
>
>>*And really nice if there were at least a
>>/usr/doc/cygwin/cygserver.readme*  Nothing fancy, just tell what we
>>should expect and what to be wary of.
>>    
>>
>
>As I just mentioned in a different thread and as I kept forgetting to
>mention earlier in this thread, cygserver (at the moment) does
>(effectively) nothing (the entry points for the IPC calls are
>deliberately missing from the DLL export list).  I could (and probably
>should) write a README to that effect.  (Watch this space etc.)
>
Well, for something that "does nothing" it has an amazing effect on my 
processing!!   Without it I hang up 100% of the time [the other thread]. 
 With it I run much more quickly and I do, sometimes, run to completion.

>Which brings me to the question: why are you running cygserver at all?
>
Started just to see what would happen.  Liked the result, stayed with it.

>In another message in this thread, you mention that the configure ran
>more quickly with cygserver than without.  This is probably due to the
>/tmp/cygdaemo socket file I mentioned in another thread.  If you run
>cygserver and then kill it, it leaves this file behind, which causes all
>cygwin processes to pause for a second (or so).  So, if you've run
>cygserver and are no longer running it, find and remove the
>/tmp/cygdaemo file.  Don't remove it if you are currently running
>cygserver.
>
Roger.

>Of course, the main advice is just not to run cygserver at all right
>now, since it doesn't provide any functionality.
>
>As for your other point about stdout redirection problems when running
>cygserver, I find it hard to see how this has anything to do with
>cygserver especially since you say the redirection file doesn't even get
>created.  The file is created by the shell itself and for this not to
>happen indicates that something wierd and wonderful is happening.
>
Hypothesis: the stdout /is/ written, however for whatever reason it 
isn't being properly  closed.  Thus it never gets a good directory 
entry.  I haven't run the disk scan in a while.  HOLD ON.  . . . .   
Well, no lost chains or other filesystem faults, anyway.  It appears 
only to happen if the redirected file is pretty large -- this would 
match Nicholas's experience.  If I do a "normal" experiment with a real 
small stdout ( echo "`date`" ) the file IS created and correct.  If I do 
a configure or make that would be expected to generate a very LARGE file 
-- nope!  no file.  And it's obvious that if NO redirection worked, 
configure and make would suffer a very early demise.

Just the kind of error I especially hate.  What's happening is clearly 
important.

>In any case, as I mentioned before, I need to see the
>`cygcheck -s -v -r' output from your machine before we can get any
>further with this.
>
I hope, by now, you've seen one of the two I've posted!
-- 

David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/