Re: Performance monitor signal handler

Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> >     Does  a pipe guarantee that a buffer, written with one atomic
> >     write(2), never can get intermixed with  other  data  on  the
> >     readers  end?
>
> Yes.  The HPUX man page for write(2) sez:
>
>           o  Write requests of {PIPE_BUF} bytes or less will not be
>              interleaved with data from other processes doing writes on the
>              same pipe.  Writes of greater than {PIPE_BUF} bytes may have
>              data interleaved, on arbitrary boundaries, with writes by
>              other processes, whether or not the O_NONBLOCK flag of the
>              file status flags is set.
>
> Stevens' _UNIX Network Programming_ (1990) states this is true for all
> pipes (nameless or named) on all flavors of Unix, and furthermore states
> that PIPE_BUF is at least 4K on all systems.  I don't have any relevant
> Posix standards to look at, but I'm not worried about assuming this to
> be true.
   That's good news - and maybe a Good Assumption (TM).

> >     With message queues, this is guaranteed. Also, message queues
> >     would  make  it  easy  to query the collected statistics (see
> >     below).
>
> I will STRONGLY object to any proposal that we use message queues.
> We've already had enough problems with the ridiculously low kernel
> limits that are commonly imposed on shmem and SysV semaphores.
> We don't need to buy into that silliness yet again with message queues.
> I don't believe they gain us anything over pipes anyway.
  OK.

> The real problem with either pipes or message queues is that backends
> will block if the collector stops collecting data.  I don't think we
> want that.  I suppose we could have the backends write a pipe with
> O_NONBLOCK and ignore failure, however:
>
>           o  If the O_NONBLOCK flag is set, write() requests will  be
>              handled differently, in the following ways:
>
>              -  The write() function will not block the process.
>
>              -  A write request for {PIPE_BUF} or fewer bytes  will have
>                 the following effect:  If there is sufficient space
>                 available in the pipe, write() will transfer all the data
>                 and return the number of bytes  requested.  Otherwise,
>                 write() will transfer no data and return -1 with errno set
>                 to EAGAIN.
>
> Since we already ignore SIGPIPE, we don't need to worry about losing the
> collector entirely.
   That's  not  what  the manpage said. It said that in the case   you're inside PIPE_BUF size and using O_NONBLOCK,
you either   send complete messages or nothing, getting an EAGAIN then.
 
   So  we  could  do the same here and write to the pipe. In the   case we cannot, just count up and try  again  next
year (or   so).
 

>
> Now this would put a pretty tight time constraint on the collector:
> fall more than 4K behind, you start losing data.  I am not sure if
> a UDP socket would provide more buffering or not; anyone know?
   Again,   this   ain't  what  the  manpage  said.  If  there's   sufficient space available in the pipe  in
combination with   that  PIPE_BUF  is  at least 4K doesn't necessarily mean that   the pipes buffer space is 4K.
 
   Well,  what  I'm  missing  is  the  ability  to  filter   out   statistics reports on the backend side via
msgrcv(2)smsgtype   :-(
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com