OZ@WISCPSL.BITNET (Jim Osborne) (07/19/88)
Someone asked if there was a way for a process to be notified when a file is created in a directory--I think so the process wouldn't have to scan periodically (with system overhead traded against response time) for new files. Was it Jamie Hanrahan of Simpact who suggested taking out the locks RMS takes and using a blocking AST? I was intrigued enough to investigate (hack). If anyone is interested in the working but unpolished program I've written, I'll send it to them (4 files, 709 lines). A quick description: A detached process (running WATCH.EXE) accepts requests to monitor files, to stop monitoring files, and to shut itself down through a mailbox. WATCH $WAKEs a "client" when the file it asked WATCH to monitor is modified. In the case of a directory file, this indicates that a file was created or deleted in the directory. WATCH uses standard $ENQ[W] and $DEQ system service calls to acquire and release its locks. The locks are (necessarily) taken out in KERNEL mode, with a blocking AST which converts the locks to NLMODE to allow the blocked requests to be granted, then converts them back to the original mode. When this conversion completes, WATCH $WAKEs the client process. WATCH runs in USER mode except during the $ENQ[W] and $DEQ system service calls. If WATCH's process is deleted, all its locks are released and RMS can get back into its groove. KNOWN SHORTCOMINGS: o I don't understand RMS file locking much and don't think I catch all file modifications--though directory watches work. OPEN/APPEND seems to slip by me. o I don't understand multivolume sets much (having never experienced one) and don't think WATCH will work with files located on them. o It doesn't let clients know if the watch failed to be enabled. o It creates the mailbox with S=O=G=W:RWLP (default) protection. o It lets anyone issue to EXIT command. o It notifies clients via $WAKE, as opposed to something fancier like a mailbox message, common event flag, etc. o It writes (too many) status messages with QIOWs to TT: since RMS can't be used from KERNEL mode AST level--where much of the fun happens and many of the status messages are generated. Maybe status messages could be inserted into a queue which is dumped by a USER mode AST: if (LIB$INSQTI(x,x).eq.LIB$_ONEENTQUE) call SYS$DCLAST(x,x,U) o It doesn't check that it's not watching the same file twice. This causes an infinite loop as WATCH fires its own blocking ASTs when it converts its locks! WATCH should either disallow it or share the same lock between multiple clients. o I haven't written any kind of documentation for the commands: 'WATCH filespec', 'STOP [filespec]', 'EXIT' I CANNOT TAKE RESPONSIBILITY FOR ANYTHING BAD THAT MIGHT HAPPEN TO ANYONE WHO USES THIS PROGRAM (OR TO THEIR SYSTEMS). UPPERCASE IS INTIMIDATING. Any takers?