Very Computer

  Hi,
    I am trying to find a way in which I can read /dev/log, and not
  interfere with syslogd.  I think what I would like to do is basically a
  'tee' of everything that comes into /dev/log.  Has anybody done this or
  have any suggestions on how to?  I have thought of the following.

     1)  Possible creating a line in the syslog.conf file that puts all
       messages to a pipe and reading from that pipe.

     2)  Replacing /dev/log with something that does the exact same thing
       execpt write incomming messages to another pipe as well.

     3)  Change the syslog.conf file to create a seperate file for each of
       the message types.

    I would like to be able to use pipes that way I would be notified
  when something has arrived, instead of having to read a file.  

  Thanks in advance,
  Rindress

------------------------------------------------------------------------------
                   Name: Rindress MacDonald

Disclaimer:  The opinions expressed herein are not that of Cabletron Systems.
------------------------------------------------------------------------------

Thanks.
Pratheep.
--
Pratheep K.Chidambaram

If that is all you want to do, why not simply change syslog.conf to
send you mail?  Much simpler, and fully supported.
--

Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.

PS: I'm back!

What do you have against semaphores ?

The only way I can think is to "emulate" the semaphores using a few
bytes of the shared memory segmente.
When any process wants to read or write it will check a given byte, if
it is '1' then someone is writing, than wait a random time and try
again until that byte became '0', when that happen it's safe to read
the data, but if that process wants to write it will have to set that
byte to '1' first.

But I'm not sure what will happen if a process starts to write just
after another process started reading... Will the read end first and
the data is correct or could the write overwite what is beeing read in
that moment ??? If this is possible then you'll have to use another
byte as a read flag, and any process that wishes to write will have to
wait until all the others end the reading (this may take a long time
if you have a lot of readers). You may use a 3th byte as a 'whish to
write' flag. When a process wants to write it will set this byte and
no new readings will be done.

Please note that I've never done this before, I'm just speculating
about it. Maybe I'm right, but maybe I'm not...

--

regards,
  _____

: What do you have against semaphores ?

: The only way I can think is to "emulate" the semaphores using a few
: bytes of the shared memory segmente.

[alternative semophore method deleted..]

All that is fine, but defeats the whole purpose of semophores, which
is to do these operations _atomically_.  If you can't obtain and
release acess to the shared segment atomically, there's never any
guarantee that both processes won't be acessing it at the same time.
Semophores are the only facility for doing this, and they are simple
to implement. See semget(2), semop(2), semctl(2), stdipc.

-Glenn.

: : What do you have against semaphores ?

: : The only way I can think is to "emulate" the semaphores using a few
: : bytes of the shared memory segmente.

: [alternative semophore method deleted..]

: All that is fine, but defeats the whole purpose of semophores, which
: is to do these operations _atomically_.  If you can't obtain and
: release acess to the shared segment atomically, there's never any
: guarantee that both processes won't be acessing it at the same time.
: Semophores are the only facility for doing this, and they are simple
: to implement. See semget(2), semop(2), semctl(2), stdipc.

Well, you don't want to just twiddle bits/bytes in shared memory, as
it leaves holes in your logic (small timing related holes that won't
show up in testing).  If you don't want to use sysv semaphores,
you need to use the atomic load/stores that all modern processors have.

A typical use is for multiple processes to mmap() an common object and
agree to a set of bytes as read/write flags and to use the atmoic instructions
to access these bytes. This method can be much (many times) faster than
useing the system semaphores, depending on the application. The main
advantage is that you stay in user-space, and don't invoke a kernel trap.

System V semaphores are unduely complex for most purposes, but do offer
portability and a clean-up feature when process goes away.
larry-

The other way of doing it is to lock a file when entering the critical region
and to unlock it when everything is done. This is the method suggested by
R. Stevens in Advanced Programming in the Unix Environment.

Hope this helps,

Fabio
------------------------------------------------------------------------

Department of Computing Science
University of New England - Armidale
Armidale  NSW  2350
AUSTRALIA
------------------------------------------------------------------------
Nixon's Theorem: "The man who can smile when everything is going wrong
                  has just worked out who to blame it on."

The only time I've been able to use shared memory without semaphores is
when I had an array where only the children could write to, and one
other structure where only the controlling process could write to.

--
Alex Ramos            | Electrical Engineering | Fala-se Portugues, tche!

"Use recycled nuclear weapons."

You are probablly right, but when I use the word "byte" I was thinking
about some kind of flag that may be accesses by evryone, I didn't know
about that strange (for me) beaveour of the Alpha processor.

: The other way of doing it is to lock a file when entering the critical region
: and to unlock it when everything is done. This is the method suggested by
: R. Stevens in Advanced Programming in the Unix Environment.

Lock a file ? But we are talking about sharedmem...
--
Regards,

       / /\  /\  _________\
      / /  \ \ \ \___ __  /        Antonio Vasconcelos
     / / /\ \ \ \ \  / / /  Bolsa de Valores de Lisboa
    / / /\ \ \ \ \ \/ / /      [Lisbon Stock Exchange]
   / /_/__\ \ \ \ \/ / /         R. dos Fanqueiros, 10
  /________\ \ \ \  / /                    1100 LISBOA
  \___________\/  \/_/                        PORTUGAL

But there ain't no 'simultaneously' things...
Well, maybe in a multi-processor environment this may happen...

: Alex Ramos            | Electrical Engineering | Fala-se Portugues, tche!
                                                   ^^^^^^^^^^^^^^^^^
Por aqui tambem, mas sem o 'tche'... :-)
--
Regards,

       / /\  /\  _________\
      / /  \ \ \ \___ __  /        Antonio Vasconcelos
     / / /\ \ \ \ \  / / /  Bolsa de Valores de Lisboa
    / / /\ \ \ \ \ \/ / /      [Lisbon Stock Exchange]
   / /_/__\ \ \ \ \/ / /         R. dos Fanqueiros, 10
  /________\ \ \ \  / /                    1100 LISBOA
  \___________\/  \/_/                        PORTUGAL

        Task 1                          Task 2

        Gee, I think I'll read
        the semaphore flag.
        Hmm... It seems to be clear

                >>>-----------> Context switch >>>--------->
                                        Gee I think I'll read the
                                        semaphore flag.
                                        Hmm...  It seems to be clear.
                                        Now I think I'll set it.
                                        Now on to some semaphore
                                        related stuff....

                <-----------<<< Context switch <---------<<<
        Gee, the flag was clear, so
        I think I'll set it.
        Now I'll do my semaphore
        related stuff....

                >>>-----------> Context switch >>>--------->
                                        Ok.  I'm done with the semaphore
                                        stuff.  I'll clear the flag.
                                        (other junk)

                <-----------<<< Context switch <---------<<<
        Ok.  Time to clear the flag.

Basically, you have to ensure that a context switch doesn't occur between
the time that a process tests and sets the flag.  If it does, you have
no guarantee that another process won't test the flag immediately after
you test the flag.

There are ways to get around this without an atomic test-and-set instruction
in your machine's instruction set.  The Amiga, for example, has two functions, Forbid()
and Permit(), which disable and enable (respectively) context switches.

So, you do something like this:

        Forbid();
        localflag = the_flag;
        the_flag = 1;
        Permit();

        if (!localflag)
                {
                /* the_flag was unset */
                whatever ();
                }
        else
                {
                /* the_flag was set */
                wait_around_or_something();
                }

If you don't have an atomic test-and-set instruction, though, I think
it can be done with an addition (provided the addition instruction
is atomic).  The semaphore flag is an integer where zero represents
clear.  To test/set the flag, you add one to it, and the check its
value.  If the value is one, then you were the only person to add to
it.  If the value is more than one, the semaphore is already in use.
If it's in use, you subtract one from it.

Adios,
  Logan

--

He was desperate then he found the open gate ___///__
Guards were standing there all day ______________/___           I do not
Something made them look the other way __________/___          speak for
      -Elim Hall, "Testimony" ___________________/___             Pencom