Greetings, Daniel

Replying to a message of Daniel Lynes to Francois Thunus:

 DL> Hello Francois!

 DL> 16 Jun 96 21:48, Francois Thunus wrote to All:

 FT>> way to do this without consuming any resources ? the doc talks
 FT>> about threads for the muxwait, which is why I am not sure I can
 FT>> use it between 2 apps.

 DL> The semaphores are designed for threads; I'm not sure if you can use
 DL> them for inter-process communications or not, just inter-thread
 DL> communications.

Semaphores are designed for inter-process, not inter-thread.  Since they
are globally available, threads may use them, but just as often, critical
sections may be used to a greater efficiency as they have lower overhead
(if they are the same as the WinNT versions of these functions, which is
likely considering their common base).

 DL> However, you might try using a duplex pipe, or creating a 0 byte file
 DL> at the outset; if that 0 byte file exists, a process has started up;
 DL> else, go ahead and run.  This is the way I've got
 DL> BinkleyTerm/Squish/Maximus configured, to avoid having more than one
 DL> program writing to the message base at once (Maximus does it
 DL> automatically, but GoldEd/2 doesn't, so I need to create a tag file,
 DL> so that when an import/export starts running, it checks for the tag
 DL> file first, before invoking squish.)

GoldEd/2's scan of the bases will not harm the bases if another process is
working with them.  Max and Squish use semaphores (BBSSEM's environment
variable, otherwise /sem/squish/default) to lock the bases.  The only
"harm" comes from writing in GoldEd/2 while tossing is going on
in the same area.  (This includes editing the message to write while
tossing happens in that area.)  However, no long-term harm erupts ... it
won't even require sqfix to be executed.

Until next time,
Darin McBride

--- FleetStreet 1.16 NR