From: Joseph McDonald <joe@...>
Date: 2001-07-04T12:40:20+09:00
Subject: [ruby-talk:17208] ruby community


You might remember that thread on "ensure block not being called" that
I started. It turned out that there was a bug in sysvipc.c Guy Decoux
determined that it was not threadsafe. So I privately asked Guy to
explain to me what that meant, and to fix one function in a tutoring
fashion , and I would fix the rest, and even more, I would try to use
my new found knowledge to fix fastcgi which also is not threadsafe.

Well, Guy totally came to the rescue, he dissected a bad function and
explained to me that when something is said to not be "thread safe" it
means that you have made a system call that could block, and you need
to deal with that situation.  The way to deal with such a situation is
something like this (if I understood correctly):

  If you have given the user an option for setting a flag to tell the
  function not to block, you return immediately if you are blocked
  (and tell the caller). If the user did not specify that it should be
  a non-blocking call, then you give that system call a flag that
  tells it not to block, and put it in a "while loop" which also calls
  rb_thread_sleep(1) while it is waiting for data. So, you would
  change this:

  rlen = msgrcv (msgid->id, msgp, len, type, flags); /* could block */

  To this:

  if (flags & IPC_NOWAIT) { /* don't block */
      rlen = msgrcv (msgid->id, msgp, len, type, flags);
  }
  else {
    flags |= IPC_NOWAIT;
    while ((rlen = msgrcv (msgid->id, msgp, len, type, flags)) == -1 &&
           errno == ENOMSG) {
        rb_thread_sleep(1);
     }
  }
    
I think that's pretty good info to have if you're writing ruby
modules!  I made a similar change to the only other function that
needed it, and sent it on to the sysvipc creator.

Also, Guy found a couple of memory leaks as well. All of this was
passed on to the creator and owner of the sysvipc module (Daiki Ueno)
and he has put his fix in (it's not quite the same fix, and there is a
question as to which is better, you can see the changes on his cvs:
http://deisui.bug.org/cgi-bin/viewcvs.cgi/sysvipc/

So now ruby has a better sysvipc interface!  A very good thing I
think.

All of this long-winded note is for a couple of reasons, the
first is to publicly thank Guy and Daiki, and the second is to give a
big cheer to the community that fosters this sort of progress.

Oh yeah, and to prepare you for my inevitable dumb questions as I look
into this fastcgi thing :-)

thanks,
-joe