gmane.comp.lang.ruby.posix-mq.general

Re: Listing existing queues

Iñaki Baz Castillo — 2011-06-22T20:09:27

2011/6/21 Eric Wong <normalperson< at >yhbt.net>:

Sure :)



And sometimes never happens :)

Thanks a lot.

Re: Listing existing queues

Eric Wong — 2011-06-21T18:24:49

Start using MQ more and get more people to use software that uses it.

Also go to the Linux Standards Base and try to get it in the new
Filesystem Hierchy Standard (to be finalized/released soon).

Try to get it into POSIX.

Also start talking to major distro maintainers/vendors to move towards
this.

Standardization is hard, and takes many years :)

Re: Listing existing queues

Iñaki Baz Castillo — 2011-06-21T13:03:37

2011/3/3 Eric Wong <normalperson< at >yhbt.net>:

Hi Eric, I continue with same problem (of course, since there is not
yet standarization for mounting Posix MQ's in a specific path).

So, what can we do in order to "impact" in the standarizing of Posix
MQ mount mount? :)

Re: examples of POSIX message queue usage in the wild?

Iñaki Baz Castillo — 2011-03-03T22:05:52

2011/3/3 Eric Wong <normalperson< at >yhbt.net>:

I do know that a comercial SMPP Gateway (SMS stuff) uses posix message
queues under Linux. Sure (as we use it in my company).
I prefer not to say the product name as the software internals are not public.

Also, if you wait a bit I am coding a SIP server in Ruby which makes
*extensive* usage of your posix_mq gem :)

Re: Listing existing queues

Eric Wong — 2011-03-03T22:02:14

The standard would be a filesystem mount point.  Things like /tmp/ and
/home/ are already more/less standardized nowadays.

Linux (following Plan 9's (and Unix's) lead that "everything is a file")
is already moving more and more things into the filesystem or file-like
features (signalfd/timerfd/eventfd) and avoiding specialized APIs for
signals/timers/events.


My personal preference is smaller APIs and more reuse of existing ones
whenever possible.

Re: Listing existing queues

Iñaki Baz Castillo — 2011-03-03T21:49:00

2011/3/3 Eric Wong <normalperson< at >yhbt.net>:

Not sure if I understand you. Do you mean that, hopefully in a future
all the Linux/BDS systems will mount posix mqueues in the filesystem?
Some Linux kernels come without support for posix mq (not compiled).
Anyhow, assuming posix mq was widely adopted and extended, how could
we be sure that all the systems would use the same mount point?

Maybe I miss something, but I still think that a simple API funcion
"mq_list" which returns an array of char* representing each existing
mqueue name would be easier.

Cheers.

examples of POSIX message queue usage in the wild?

Eric Wong — 2011-03-03T21:43:50

Just wondering if there is any reasonably well known software that uses
POSIX message queues .  It doesn't matter what language it is, I haven't
encountered anything other than my own experiments[1] really.


[1] http://mmq.bogomips.org/ + http://bogomips.org/mmq.git (C, not Ruby)

Re: Listing existing queues

Eric Wong — 2011-03-03T21:39:11

Yes.  However given the small number of POSIX message queue users and
systems supporting it, I still see the feature as being in the early
adopter phase and still has room to standardize on using the filesystem
like Linux.

And being early adopters of POSIX message queues, we (Ruby POSIX_MQ
users/developers) have some ability to impact the standardizing of
listing queues via the filesystem :)

Another thing I really, really like is that mq descriptors are mapped to
file descriptors in FreeBSD and Linux, so hopefully other kernel
implementers follow their lead and make it easy to poll()/select() on.

Re: Listing existing queues

Iñaki Baz Castillo — 2011-03-03T05:08:37

2011/3/2 Eric Wong <normalperson< at >yhbt.net>:

The problem is that if you provide a software that others can download
and use in their computers, you can not rely on the existence of the
filesystem approach :(

Re: Listing existing queues

Eric Wong — 2011-03-02T19:38:15

Nothing that I know of, I do prefer the filesystem approach of Linux as
opposed to having a specialized API, though.

Listing existing queues

Iñaki Baz Castillo — 2011-03-02T12:35:05

Hi, is there any way to list the existing posix message queues? I mean
without habing to mount the posix mq filesystem.
I've not found how to do it with the C API provide by posix mq.

Thanks.

Re: [ANN] posix_mq 1.0.0 - kinder,gentler message queues

Iñaki Baz Castillo — 2011-03-01T22:56:32

2011/3/1 Eric Wong <normalperson< at >yhbt.net>:

I was waiting for this release for upgrading my gem:

   https://github.com/ibc/em-posixmq/commit/87855f4efcc88ca140770e751bd80df0b9262b14

:)

[ANN] posix_mq 1.0.0 - kinder, gentler message queues

Eric Wong — 2011-03-01T09:21:44

POSIX message queues allow local processes to exchange data in the form
of messages.  This API is distinct from that provided by System V
message queues, but provides similar functionality.

* http://bogomips.org/ruby_posix_mq/
* ruby.posix.mq< at >librelist.com
* git://bogomips.org/ruby_posix_mq.git

Changes:

There is one backwards-incompatible API change:

  POSIX_MQ#send returns +true+ on success instead of +nil+
  for consistency with POSIX_MQ#trysend.

This release adds the POSIX_MQ#trysend, POSIX_MQ#tryreceive and
POSIX_MQ#tryshift interfaces to avoid exceptions on common
EAGAIN errors for users of non-blocking queues.

Bugfixes: non-blocking behavior changes to a shared descriptor
in a different process are reflected immediately in the child
(this won't fix race conditions in your code, however).
Minor bugfixes for posix-mq-rb(1) and quieted warnings for
1.9.3dev.

Re: [RFC] try* interfaces in posix_mq 0.8.0pre

Eric Wong — 2011-02-27T23:51:50

I actually considered doing something with POSIX_MQ#<<, but then I
realized people would expect to use it like an Array or Queue and
chain messages to it:

   mq << "FOO" << "bar"

They'd still get an exception if it returned anything other than the
mq object since the << fails on symbols/nil/false.

I considered an interface like this that would work like try/catch:

   mq.try do
     mq << "FOO" << "bar"
   end

But there's no telling at which point ("FOO" or "bar") the pushing
failed, either.   So I think << is really only good for people doing
blocking mq_send() (which I mainly use myself).

Thanks for the feedback!

[RFC] try* interfaces in posix_mq 0.8.0pre

Iñaki Baz Castillo — 2011-02-27T23:23:02

2011/2/27 Eric Wong <normalperson< at >yhbt.net>:

It looks just correct IMHO. Just one question: how about << method?
Currently it behaves as POSIX_MQ#send method (raises in non-blocking
mode id it cannot write) but it returns the POSIX_MQ instance itself
when success. I suggest that it could return true on success (as you
suggest for send method).
However it could also possible that << would behave as trysend
(returning true/false), but it would break backward compatiiblity.



Sure.



I don't check it as for now it doesn't make sense (nil says nothing,
and I already rescue the possible exceptions).



Regards.

--
Iñaki Baz Castillo
<ibc< at >aliax.net>

Re: [RFC] try* interfaces in posix_mq 0.8.0pre

Eric Wong — 2011-02-27T22:27:08

The gem is installable via "gem install --pre posix_mq" from
RubyGemms.org


I use "make gem" to generate teh manifest and gem in one go.

Re: [RFC] try* interfaces in posix_mq 0.8.0pre

Iñaki Baz Castillo — 2011-02-27T16:15:06

2011/2/27 Iñaki Baz Castillo <ibc< at >aliax.net>:

Apart from these temporal issues I've tested tryreceive and trysend
and they work well (as expected).

Re: [RFC] try* interfaces in posix_mq 0.8.0pre

Iñaki Baz Castillo — 2011-02-27T15:01:20

2011/2/27 Iñaki Baz Castillo <ibc< at >aliax.net>:

Hi Eric, I've cloned your repo and want to test it by building and
installing the gem but have found various issues:

- File .manifest doesn't exist (touch .manifest does the work).
- gemspec doesn't include lib/posix_mq.rb so such file is not
installed and the gem cannot be loaded.

Re: [RFC] try* interfaces in posix_mq 0.8.0pre

Iñaki Baz Castillo — 2011-02-27T14:44:07

2011/2/27 Eric Wong <normalperson< at >yhbt.net>:

Hi Eric, nice addition. In my benchmarks raising/rescuing exception is
really expensive. When a Ruby server gets congested and starts
raising/rescuing exceptions things become even worse. So I strongly
agree with your new features (similar to Gio in Unicorn, right?) :)

I will test it ASAP and comment here.

[RFC] try* interfaces in posix_mq 0.8.0pre

Eric Wong — 2011-02-27T11:26:12

I just pushed this out to RubyGems.org (and ruby_posix_mq.git).
Let us know what you think, thanks!

  posix_mq 0.8.0pre - kinder, gentler and less exceptional

  This adds trysend, tryreceive, and tryshift interfaces to avoid
  exceptions on common EAGAIN errors for non-blocking users.  EAGAIN
  during non-blocking messages is common when there are multiple
  readers/writer threads/processes working on the same queue.

  trysend is like send, except it returns true for success and false for
  EAGAIN.  send (still) returns nil, which I now consider a mistake but
  won't change until post-1.0...

  tryreceive and tryshift are like receive and shift respectively,
  but they return nil for EAGAIN and the same return values
  for their non-shift variants.

  None of these methods call mq_setattr() beforehand to set the
  non-blocking flag, it assumes the user set it once before they were ever
  called and never changes it.  Checking/setting the non-blocking flag
  every time is needless overhead and still subjec

[ANN] posix_mq 0.7.0 - cleanups and portability fixes

Eric Wong — 2011-02-24T00:38:54

POSIX message queues allow local processes to exchange data in the form
of messages.  This API is distinct from that provided by System V
message queues, but provides similar functionality.

* http://bogomips.org/ruby_posix_mq/
* ruby.posix.mq< at >librelist.com
* git://bogomips.org/ruby_posix_mq.git

Changes:

This release now works for systems other than Linux and FreeBSD
that support POSIX message queues.  This is usable for systems
without mq_timedsend() or mq_timedreceive() but with the
non-timed variants (timeouts wont work).

Thanks to Tadeusz Bochan for testing.

Ruby posix_mq is now dual-licensed under the GPLv2 (as well as the
preferred LGPLv3) for compatibility with existing GPLv2-only code.