Date: Mon, 12 Apr 2004 11:55:51 +0300 (EEST) From: Vlad GALU <dudu@diaspar.rdsnet.ro> To: Lev Walkin <vlm@netli.com> Cc: freebsd-hackers@freebsd.org Subject: Re: SYSV message queues Message-ID: <20040412114211.P35430@qvnfcne.eqfarg.eb> In-Reply-To: <407A3076.8030005@netli.com> References: <20040412011216.P7661@qvnfcne.eqfarg.eb> <407A3076.8030005@netli.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Apr 2004, Lev Walkin wrote:
> Vlad GALU wrote:
> > Hello. I have the following scenario: one process that creates a
> > message queue and goes through it in a loop, together with another process
> > that inserts various messages into the queue. What I wish is for the
> > 'listening' process to be able to fully process the queue at a fixed
> > amount of time. In short, I'd like msgrcv() to iterate throught the queue
> > and visit every element in a single run. That set of operations being done
> > periodically.
> > Do you find this possible ? I'm quite puzzled here. I first tried
> > inserting a sleep() call in my queue processing loop but then I noticed
> > that it had a bad effect. It's true that I haven't read the man page very
> > carefully the first time. I'll blame it on the hurry.
> >
> > However, while writing this message, an idea occured to me. What
> > if I write the processing loop as follows:
> >
> > -- cut here --
> > int i;
> > while (1) {
> > i = 0;
> > msgctl(queueid, IPC_STAT, &queuestat);
> > while (i <= queuestat.msg_qnum) {
> > msgrcv(queueid, &message, sizeof(message), 0, 0);
> > process_message(message);
> > i++;
> > }
> > sleep(5);
> > }
> > -- and here --
> >
> > Does this look pheasible ? I'm expecting an injection of about
> > 100k messages per second or even more. There'll be quite a lot of
> > unprocessed ones at the end of each run, I suppose. I'll measure the average time spent for
> > one run and decide on the sleep interval.
>
>
> Did you try to grok what the msgrcv() call is supposed to return?
> Specifically, read about -1/EAGAIN and IPC_NOWAIT. Then remove sleep().
>
It is supposed to block, waiting for more events to be inserted
into the queue.
> > However, does anyone have a better design ?
>
> Yes. Use sockets.
My program currently uses sockets. I found it easier to write
clean code with SYSV SHM. In fact, I turned to a SYSV message queue
because I wanted to rely on the kernel to manage it, rather than doing it
myself. Of course, this raises some portability problems, but the goal of
the software I'm currently writing is very biased. It will only run on
FreeBSD, so I guess there's no problem with that.
>
> Obsolescent Unix IPC Methods
> http://www.catb.org/~esr/writings/taoup/html/ch07s03.html#id2923376
>
Thanks. That was a nice reading material. I don't entirely agree
with it though. It has some strong points against using shared memory
areas and/or threads. Unfortunately, theory often does not apply in
practice. I think' it's easier for one to program using one of the above
methods. Nowadays most UNIX software makes use of them.
> --
> Lev Walkin
> vlm@netli.com
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
----
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040412114211.P35430>