Path: utzoo!attcan!uunet!super!udel!gatech!bloom-beacon!think!ames!pasteur!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: How to close a device
Message-ID: <8812232121.AA02267@postgres.Berkeley.EDU>
Date: 23 Dec 88 21:21:15 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 33


	You have it correct.  Actually, if the IORequest is not active,
(it had better not be active if you are closing the device!) it doesn't 
really matter whether you deallocate the reply port first because the device
only uses the reply port to return packets.

	A commonly misunderstood problem is that of multiple requests on
the same device.  You allocate two or more requests, OpenDevice() one of
them, then copy it's now initialized contents to the other requests.  For
example if fooling around with the serial.device you most likely want two
IORequests ... one for reading and one for writing.

	When you eventually want to close the device, you must AbortIO()/
WaitIO() any active requests (i.e. all requests must be owned by you), then
close the device using one of the requests (doesn't matter which), then
deallocate the requests.

					-Matt

:  What is the *correct* order to close a device and free buffer memory &
:replyports?
:  The RKM examples does this in several ways, but my cautious mind says that
:one should *first* close the device to prevent access to buffers etc, *then*
:free the buffers. It looks like the RKM examples would work in 99% of the
:cases...
:
:  Currently, I'm doing this (where ReadRequest is a struct IOExtSer *):
:
:  if (ReadRequest) {
:      CloseDevice(ReadRequest);
:      DeletePort(ReadRequest->IOSer.io_Message.mn_ReplyPort);
:      FreeMem(ReadRequest, sizeof(*ReadRequest));
:  }