Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!fernwood!uupsi!sunic!dkuug!diku!bombadil
From: bombadil@diku.dk (Kristian Nielsen)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Can you call DeviceProc() from a Task?
Keywords: DeviceProc() dos.library dos process
Message-ID: <1991Jun21.115530.20538@odin.diku.dk>
Date: 21 Jun 91 11:55:30 GMT
References: <6101@walking.pub.uu.oz.au>
Sender: bombadil@freja.diku.dk
Organization: Department of Computer Science, U of Copenhagen
Lines: 47

david@walking.pub.uu.oz.au (David Le Blanc) writes:

>I would like to know if DeviceProc() and IoErr() can be called from a task?

>DeviceProc() does not seem to be like 'Read()' in that it does not use
>messages to accomplish its task. (Ie, it goes to the DOS list to find the
>process)

  Except if it needs to start up a new handler process, for example if it is a
con: type handler, or a first reference to a resident handler. In this case,
it needs to send the startup-message to the handler. Of course, even if you
know that the handle is already loaded, the situation might change n a future
os version (and you might be wrong).

>How about IoErr()? Where does it find its Error code? I am pretty sure it
>goes to PROCESS->pr_Result2, in which case NO you can't use it in a task.

  The solution I curently use (for putting a handle on top of another one,
like you) is to fire up a separate process to execute the DeviceProc() and
IoErr(), sending the result back by a PutMsg(). This shouldn't be too
expensive in most cases, since DeviceProc typically will be called only once.

  Actually, this strategy seems to solve only part of the problem. Lets say
that you want to start up a con: debug window. So, you handle fires up a
process that in turn calls DeviceProc(), starting a con: process. A
startup-packet is sent, and we wait for the packet to return. Under 1.3,
this works just fine. When I had a chance to try it under 2.0, however,
something very strange happened. The con: window opens up as it should. How-
ever, the DeviceProc() never returns. Xoper reveals that my process is execu-
ting in DeviceProc(), but waiting for signal 4. However, the con: process sends
the packet (as it should) to the DOS port of the handler, which uses signal
8. So there my process is, waiting for signal 4, which never arrives, though
signal 8 is set as it should be - deadlock. Any suggestion as to whats
happening? If i set signal 4 myself (manually), everything runs fine from
then on. I thought maybe AmigaDOS 2.0 has semaphore locking of the device
list from the starting of a handler to the return of the startup-packet? Or
perhaps a bug in KS2.0, like Wait(8<<1) instead of Wait(1<<8)? (Not very
likely, really). Perhaps someone knows what signal 4 is used for? (Randell?)

  Anyway, the strategy does seem to work for referencing filesystem type
handlers (you could try not executing DeviceProc() until after you return
the startup-packet). I'm not aware of any rules in the RKM's or the AmigaDos
manual that the method breaks.

	I hope this helps (and that perhaps someone can clarify the above)

	-Kristian.