Forum: Ruby ruby/dl question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-02-11 04:30
(Received via mailing list)
if one has:


  struct flock {
      ...
      short l_type;    /* Type of lock: F_RDLCK,
                          F_WRLCK, F_UNLCK */
      short l_whence;  /* How to interpret l_start:
                          SEEK_SET, SEEK_CUR, SEEK_END */
      off_t l_start;   /* Starting offset for lock */
      off_t l_len;     /* Number of bytes to lock */
      pid_t l_pid;     /* PID of process blocking our lock
                          (F_GETLK only) */
      ...
  };

can this structure be desribed using ruby/dl?  i'm worried that the
struct
method assumes the fields are in order which, in the case of the flock
structure, they may not be.

regards.

-a
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2006-02-11 19:34
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
>      off_t l_start;   /* Starting offset for lock */
>      off_t l_len;     /* Number of bytes to lock */
>      pid_t l_pid;     /* PID of process blocking our lock
>                          (F_GETLK only) */
>      ...
>  };
>
> can this structure be desribed using ruby/dl?  i'm worried that the struct
> method assumes the fields are in order which, in the case of the flock
> structure, they may not be.

I don't understand. If the flock struct fields are not in a predictable
order, how do you access them in C?
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-02-11 21:07
(Received via mailing list)
On Sun, 12 Feb 2006, Joel VanderWerf wrote:

>>                          SEEK_SET, SEEK_CUR, SEEK_END */
>
> I don't understand. If the flock struct fields are not in a predictable
> order, how do you access them in C?

that's what to compiler does - it's why one must say

   sizeof(mystruct)

vs.

   sizeof(int) + sizeof(float)

assuming

   struct mystruct { int i; float f; };

i recently learned of the offsetof macro which tells you this info.

regards.

-a
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2006-02-11 21:58
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
> On Sun, 12 Feb 2006, Joel VanderWerf wrote:
...
>> I don't understand. If the flock struct fields are not in a predictable
>> order, how do you access them in C?
>
> that's what to compiler does - it's why one must say
>
>   sizeof(mystruct)
>
> vs.
>
>   sizeof(int) + sizeof(float)

Ah I see. It isn't that the data structure itself is unpredictable (I
thought maybe you had to read one of the fields to know how the others
are laid out). It's rather that you don't know what the compiler is
doing with it.

Since there are a variety of alignment and packing options in any
compiler, I don't see how DL could guess what the correct ones are.
Maybe it assumes longword alignment?

On further digging... in dl.h the extra space taken to align a short,
for example, is computed by...

typedef struct { char c; short x; } s_short;
#define ALIGN_SHORT  (sizeof(s_short) - sizeof(short))
#define SHORT_ALIGN  ALIGN_SHORT

...and this is used by the following macro, which advances the offset
var to the next aligned position...

#define DLALIGN(ptr,offset,align) {\
  while( (((unsigned long)((char *)ptr + offset)) % align) != 0 )
offset++;\
}

...to calculate the struct size in dlsizeof() in dl.c:

    case 'H':
      DLALIGN(0,size,SHORT_ALIGN);
    case 'h':
      size += sizeof(short) * n;
      break;

So I guess if you use 'H', you get aligned shorts (according to whatever
compiler flags ruby and its extensions were compiled with), and if you
use 'h' you get packed shorts.


Don't get your shorts out of alignment!  ;)
Ce60c4f78a63b0695e4dafc4bd7964f7?d=identicon&s=25 Lou Vanek (Guest)
on 2006-02-11 22:45
(Received via mailing list)
Joel VanderWerf wrote:

>>
> doing with it.
> #define SHORT_ALIGN  ALIGN_SHORT
>     case 'H':
> Don't get your shorts out of alignment!  ;)
And, for what it's worth, both gcc 3.4.4 and VC++ 13.10 pack the two
shorts together
into the same word on x86.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-02-12 00:50
(Received via mailing list)
On Sun, 12 Feb 2006, Joel VanderWerf wrote:

> Don't get your shorts out of alignment!  ;)

lol!

-a
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-02-12 08:18
(Received via mailing list)
On Feb 10, 2006, at 7:30 PM, ara.t.howard@noaa.gov wrote:

>      pid_t l_pid;     /* PID of process blocking our lock
>                          (F_GETLK only) */
>      ...
>  };
>
> can this structure be desribed using ruby/dl?  i'm worried that the
> struct
> method assumes the fields are in order which, in the case of the flock
> structure, they may not be.

You have a bigger problem, off_t is usually 8 bytes and the built-in
dl can only handle 4 byte types.  (Or, if it can handle 8 byte types,
I couldn't figure out how.)

--
Eric Hodel - drbrain@segment7.net - http://segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Ce60c4f78a63b0695e4dafc4bd7964f7?d=identicon&s=25 Lou Vanek (Guest)
on 2006-02-12 14:47
(Received via mailing list)
Eric Hodel wrote:
>>      off_t l_start;   /* Starting offset for lock */
>
>
> You have a bigger problem, off_t is usually 8 bytes and the built-in  dl
> can only handle 4 byte types.  (Or, if it can handle 8 byte types,  I
> couldn't figure out how.)

good pickup.
I would expect the higher-order word to be 0 in 99% of cases.
You could treat an 8-byte off_t field as two separate unsigned longs and
extract the two longs separately and then add them together
if the higher-order word is indeed anything but 0.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-02-12 16:20
(Received via mailing list)
On Sun, 12 Feb 2006, Eric Hodel wrote:

>>      off_t l_start;   /* Starting offset for lock */
> You have a bigger problem, off_t is usually 8 bytes and the built-in dl can
> only handle 4 byte types.  (Or, if it can handle 8 byte types, I couldn't
> figure out how.)

i can pack my own struct easily enough... but knowing the layout is
impossible.

right now i'm considering a 'configure' setup to my install that
requires the
compiler to determine the layout of the flock struct and generate ruby
code to
describe it.  that way, if your arch is standard you can use the dl
binding
with requiring a compiler and you only need one to determine struct
layout if
it's not.

might be too much work though...  an extension is what i've already done
anyhow (posixlock) but i'd just like to hook into the existing IO::fcntl
call
with the ability to apply posixlocking.

regards.

-a
This topic is locked and can not be replied to.