home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2632 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: hub-n.franken.de!sokrates!snfuchs
  2. Newsgroups: comp.sys.amiga.programmer
  3. Subject: Re: Removing a patch - solved?
  4. From: snfuchs@sokrates.franken.de (Stefan Fuchs)
  5. Message-ID: <snfuchs.0cvn@sokrates.franken.de>
  6. Date: Fri, 2 Feb 96 19:27:46 GMT
  7. Organization: USS Enterprise BBS, Fuerth, Germany, +49-(0)911-7568701
  8.  
  9. Nils Peter Sudmann wrote:
  10.  
  11. > On 01-Feb-96 12:01:01, Jimmy Westerlund (ing9435@ind.mh.se) wrote:
  12. > >In article <1433.6603T1100T1439@stud.cs.uit.no>, Nils Peter Sudmann wrote:
  13. > 
  14. > >> The problem is that some program
  15. > >>could be executing inside your patched code (and currently waiting for a
  16. > >>time slice). AFAIK there is *no* way to safely know when the last thread
  17. > of >>control has left your code (and you may unload it). So a patch should
  18. > >>actually never remove itself (only render itself inactive). I did miss the
  19. > >>previous patch discussion, but I wrote one myself and came to the above
  20. > >>conclusion. Right or wrong?
  21. > 
  22. > > Wouldn't this work:
  23. > 
  24. > > patch:
  25. > >addq.l#1,counter
  26. > 
  27. > >; Patch stuff
  28. > 
  29. > >exit_patch:
  30. > >subq.l#1,counter
  31. > >rts
  32. > 
  33. > Nope, if a task-switch occurs just after the jump to 'patch:' *but* before
  34. > the addq, you're sold. Same goes for the subq -> rts. I'ill agree that the
  35. > odds of 
  36. > this happening are pretty small. But it is not *correct*.
  37. > 
  38. Just had an idea to solve this (not very nice, I agree), but it should work:
  39.  
  40. When removing the patch first check the usecounter.
  41. If it is zero get the current pc for every task from the exec/tasklist.
  42. Compare the pc with the address of the addq.l #1,usecounter instruction and
  43. with the address of the rts instruction. If any match is found assume that
  44. the usecounter is not zero and act accordingly.
  45. If no match can be found I would say it is 100% save to remove the patch.
  46.  
  47. The pc of each task is stored on the user-stack, the pointer to the current
  48. stack position is stored in the task structure.
  49.  
  50. Might implement this in an upcomming version of patch.library.
  51.  
  52. Like to hear your opinion.
  53.  
  54.  
  55. Stefan Fuchs  snfuchs@sokrates.franken.de
  56.  
  57. --
  58.  
  59. ___ Offline Orbit v0.80 (Unregistered Evaluation Copy)
  60.