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

[Jon Trulson]

On Thu, 23 Jan 2003, Raymond Toy wrote:

> Date: 23 Jan 2003 13:17:03 -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> On Tue, 21 Jan 2003, Rine, Robert wrote:
>     >> Date: Tue, 21 Jan 2003 10:48:35 -0500
>     >> From: "Rine, Robert" <robert.rine at lmco.com>
>     >> To: "'nas at radscan.com'" <nas at radscan.com>
>     >> Subject: [nas] Clients die upon server death -- workaround?
>     >>
>     >> Hello,
>     >>
>     >> I have a question regarding the behavior of NAS clients when the server
>     >> is killed.  Currently, the app I'm working on, which acts as a client
>     >> connecting to an NAS server, dies immediately when the server is killed.
>     >> >From what I can tell, this is the default behavior.
>     >>
>
>     Jon> 	Yes...
>
>     >> My question is this: Is there any way of keeping the client app from
>     >> dying when the server it is connected to is killed?  I want the app to
>     >> continue running whether the audio is functional or not.  Lack of audio does
>     >> not diminish the functionality, and there is no reason to exit simply
>     >> because the audio is no longer working.  I've had no luck trying to solve
>     >> this, and any help will be greatly appreciated.  Thank you.
>
>     Jon> 	Not without a little hackery.  libaudio (like X11) lets you
>     Jon> specify your own error handler that will execute when such problems occur.
>     Jon> You use AuSetIOErrorHandler() to register your own handler.
>
>     Jon> 	The issue you will run into, is that after your error handler
>     Jon> returns, libaudio will then exit().  It does this because this is a fatal
>     Jon> error, and the relevant state/data structures within libaudio are no
>     Jon> longer valid.  You can edit (hack) the _AuIOError() function in
>     Jon> lib/audio/Alibint.c to not exit I suppose, but I do not know what problems
>     Jon> that would cause, or that you might later encounter if you made any
>     Jon> attempt to use the audio connection, or make any calls into libaudio...
>     Jon> Most likely the app would core later on, or upon return from
>     Jon> _AuIOError()...
>
> FWIW, XEmacs supports this and XEmacs does not crash when server goes
> away, and can reattach (I think) to the server if it should come
> back.  (I think you have to reattach manually, though.)
>
> It's been a long while since I experimented with this, but I have been
> using XEmacs with nas support for many years now.
>
> A peek at nas.c in the xemacs sources may be helpful.
>

	I did this awhile back remeber? ;-)  There was nothing I saw that
specifically handled this case.  I wonder - do you know if Xemacs is
running it's nas client code in a seperate thread/process?  This would
also be a way around the problem I believe.  I do know that once
_AuIOError() is called, the process will exit.  I just don't know how else
xemacs would survive...

> Ray
>

-- 
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.