Re: Writing Files asynchronously
- From: Kurt Bigler <kkb@xxxxxxxxxxxxxxx>
- Date: Thu, 25 Aug 2005 18:18:59 -0700
in article 1124730377.140157.50750@xxxxxxxxxxxxxxxxxxxxxxxxxxxx,
grice@xxxxxxxxxxxx at grice@xxxxxxxxxxxx wrote on 8/22/05 10:06 AM:
> I have a classic app that uses FSWrite to store text into a file.
> Ocassionally the app hangs when FSWrite is referencing a file on a
> remote volume (Sun Unix disk with an AppleTalk stack installed). The
> app will hang indefinitely (or until the user restarts the machine).
>
> The problem is probably someplace in the Unix driver code and the
> company that produced that code is gone.
>
> I would like to work around the hang condition so I thought I'd convert
> the FSWrite call to a PBWriteAsync call so I could monitor the
> operation and kill off the write operation if it exceeded some
> reasonable threshold. I coded the call up.
>
> I got the PBWriteAsync call to work to a point. If the call completes
> successfully, all is good. But when the call fails to complete, the
> code then proceeds to close the file without change and then the app
> abruptly crashes.
>
> I suspect that the PBWrite request is actually completing after the
> file is closed and writing over something that should remain untouched
> by errant applications.
>
> So I went looking for a way to kill off the pending I/O request.
>
> KillIO seemed like an obvious choice at first but I soon discovered it
> was intended to be used at the device driver level rather then the file
> I/O level.
>
> So I'm hunting for a function equivalent to KillIO that I can use with
> an async file write operation.
>
> Is there such a thing or is there a better way to work around my
> original problem?
I guess there is no way to set the time-out to a lower value? In any case
if it is the driver and not the OS that implements the time-out then this
may not help with a buggy driver.
I'm surprised to realize that there is no apparent way to unqueue a
parameter block request. This seems hard to believe.
However, FWIW, check out FInitQueue which "clears all the queued File
Manager calls except the current one". Maybe you can make this work.
I'd try to set some kind of a breakpoint (maybe use MacsBug) in your
ioCompletion routine to see if it gets called prior to the crash. If you
don't have one, add one. If you do, maybe it is your completion routine
that is crashing anyway.
As another possibility you might try altering the parameter block in order
to cancel the request (in effect). You might try setting ioReqCount to
zero. Maybe this will cause the queued request to become more innocuous if
it eventually fires. I have a vague memory that there may be a supported
way to alter a param block in order to cause the request to be cancelled.
Like maybe setting the ioResult to a certain value?
Presumably you are careful not to re-use the parameter block or associated
buffer before an existing use has completed.
-Kurt Bigler
.
- References:
- Writing Files asynchronously
- From: grice
- Writing Files asynchronously
- Prev by Date: GDB with CodeWarrior
- Next by Date: Re: GDB with CodeWarrior
- Previous by thread: Re: Writing Files asynchronously
- Next by thread: Re: Writing Files asynchronously
- Index(es):
Relevant Pages
|
