david@walking.pub.uu.oz.au (David Le Blanc) (06/18/91)
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)
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.
Now, since DeviceProc returns a lock in IoErr(), does it need to be called from
a Task?
The reason I would like to know is: I am (pretending) to write a handler,
which I am fairly certain is a DOS process (bit silly otherwise) however
I understand the calling DOS from that context is BAD since while DOS is
waiting on your pr_MsgPort for a reply to its 'Read()' or whatever,
another process may just send you a message, which usually causes some
sort of GURU (AsyncPkt usually).
Now, are there some 'clean' things I can call? Like IoErr(), DeviceProc()
etc? I am only worried because MOST dos calls can be done via a
'struct StandardPacket' with appropriate filler material, however
DeviceProc() would require me to manually scan DOS Lists, which I would
rather not do. (It is SUPPOSED to be a black box isnt it?)
Cheers!
David
--
-----------------------------------------------------------------------------
David Le Blanc UUCP (home) : david@walking.pub.uu.oz.au
david@walking ACSNET (work) : david@dogmelb.mlb.geomechanics.csiro.au
- CSIRO Division of Geomechanics - Fragment analysis and 3D Fractal imaging -
"What do you mean officer? This bike can't GO 140 km/h"
-----------------------------------------------------------------------------bombadil@diku.dk (Kristian Nielsen) (06/21/91)
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.