[nas] Clients die upon server death -- workaround?

[Jon Trulson]

On Thu, 23 Jan 2003, Raymond Toy wrote:

> Date: 23 Jan 2003 13:30:48 -0500
> From: Raymond Toy <toy at rtp.ericsson.se>
> To: jon at radscan.com
> Cc: "Rine, Robert" <robert.rine at lmco.com>,
>      "'nas at radscan.com'" <nas at radscan.com>
> Subject: Re: [nas] Clients die upon server death -- workaround?
>
> >>>>> "Jon" == Jon Trulson <jon at radscan.com> writes:
>
>     Jon> 	I did this awhile back remeber? ;-)  There was nothing I saw that
>
> I remember that just after I sent the message. :-)
>
>     Jon> specifically handled this case.  I wonder - do you know if Xemacs is
>     Jon> running it's nas client code in a seperate thread/process?  This would
>     Jon> also be a way around the problem I believe.  I do know that once
>     Jon> _AuIOError() is called, the process will exit.  I just don't know how else
>     Jon> xemacs would survive...
>
> I have no idea how it works.  That code is 5-10 years old and written
> by someone else.  But xemacs is definitely not using another thread or
> process.  nas.c is all there is.
>
> But right now, my xemacs is talking to the ausun just fine.
>
> I just killed ausun, and xemacs says the audio server connection was
> broken.  (Sound still works because it falls back to talking directly
> to the sound port.)
>
> Now I've restarted ausun.  XEmacs has now automatically connected to
> the server again and is using ausun to play sounds.  (Which I can
> easily see from auinfo because some buckets are in use.)
>
> I have no idea how this works, but I like it very much. :-)
>

	Ahh.. Another thought I had but was afraid to mention ;-).  What
they are doing is using an AuErrorHandler, that then longjmp()'s back to
the beginning on fatal error - so in effect the error handler never
returns, and therefore the exit is never called.

	At this point the nas module will then attempt to re-open the au
connection, succeeding or failing as normal when an attempt is made to
play a sound...  Intruiging ;-)

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
You talk like a Ferengi.