shell escape causes vi to lock up (SUMMARY)

chip at t4test.UUCP chip at t4test.UUCP
Fri Jun 15 11:35:38 AEST 1984


=== REFERENCED ARTICLE =============================================

From: chip at t4test.UUCP (Chip Rosenthal)

I have been having an extremely frustrating problem with vi under
Eunice.  I wonder if anybody else has seen it, and if they know what is
going on.  Sometimes, a shell escape causes you to go off into never
never land.

Has anybody else seen this?

====================================================================

Apparently, many other people have seen this.

Tom Merrick (hocda!tbm) wrote me saying:

>  Yes we have.  Happens all the time.  I tried to get a vispell working
>  yesterday and locked up every time.  No solutions, but glad to know I
>  am not alone.
>  
>  Tom Merrick ATT BTL N. Andover MA  617-681-6436

David Kashtan ( kashtan at sri-iu ) wrote to me wondering "how recent a 
version of `vi' TWG was supplying".  I don't know the answer offhand.  
Anybody out there know this?

If I put the pieces of the many postings together, it sounds to me
like `vi' is not properly reusing the suspended Eunice processes
lying around, just goes on creating more processes, and at some
point runs into its limit.  Summary of comments to this newsgroup:


J. Johnson (cornell!jqj)			<299 at cornell.UUCP>

>  A frequent cause of hanging in deeply nested process trees is exceeding
>  your max process count.  Check the entry in the AUTHORIZE database to
>  see if that is your problem.


D. Libes (nbs-amrf!libes)			<302 at nbs-amrf.UUCP>

>  This sounds like one of those "not closing all your files" problems.
>  After finding that vi didn't recompile properly as distributed, I
>  didn't look too much further at this other than to note that you can
>  execute 6 (or something like that) shell escapes before this happens
>  (yes, consistently).


J. Shapiro (jss at sjuvax)				<349 at sjuvax.UUCP>

>  When you run out of VMS processes, VMS hangs waiting for one of your
>  processes to complete before it gives you the new one.....  
>  ...after you are done with a spawned job, Eunice hangs onto it for
>  a while so that if you ask for another it can reuse it.  That catch?
>  Eunice doesn't actually seem to do the reuse part in real life.


K. Carosso (!scgdvax!engvax!kvc)		<196 at scgvaxd.UUCP>

>  When a user runs out of VMS processes, you most definately do NOT
>  hang in an MWAIT.  ...Since VMS processes share many resource quotas,
>  [it] is more likely that you are running out of some other resource
>  while you are trying to create the process.  Some resources will
>  wait in the MWAIT state for things to free up.


In summary, it looks like it has something to do with the creation of
processes, and topping out on some resource limit.  Possibly this limit
is the number of processes.  It appears that Eunice is not properly
reusing these processes.  I think we could continue to run it down
(there are some good leads already), but I feel that it is not my
responsibility to fix a broken product.  I will submit a "Modification
Request" form to TWG documenting this problem.

One thing I wonder about is given the fact that TWG wrote their own
editor (FSE), how willing would they be to support vi? By the way, has 
anybody out there used FSE?  How does it compare to a vi or emacs?


-- 
Chip Rosenthal, Intel/Santa Clara
{idi|intelca|icalqa|imcgpe|kremvax|qubix|ucscc}!t4test!{chip|news}



More information about the Comp.os.eunice mailing list