Strange behavior with freepascal and IPC Queue Message
lazarus / 66-Unix

----------------------------------------------------------------------
eolandro · 2017-04-18 06:59

I have two codes one in freepascal and anothe in php. The pascal code
creates an IPC Queue and sends one byte in that queue. If the queue
already has elements. it does not send any byte. The php code only
gets the state of the queue.

But the strange is freepascal can not get the length of the
queue(sg_qnum). This value is always zero.
In the other hand the php code gets that value without trouble.

I have no other PC maybe is my installation maybe is my code.

Can you help me test my code?

Thanks

----------------------------------------------------------------------
Thaddy · 2017-04-18 09:08

Both attachment read like a piece of shit.
Do better.

----------------------------------------------------------------------
eolandro · 2017-04-18 16:28

Quote from: Thaddy on April 18, 2017, 11:08:47 amBoth attachment read
like a piece of shit.
Do better.

Show me how. Let me see your code. An example.

----------------------------------------------------------------------
Kays · 2018-01-10 11:32

Quote from: eolandro on April 18, 2017, 08:59:54 am[…] But the strange
is freepascal can not get the length of the queue(sg_qnum). This value
is always zero. […]Yeah, this happens occasionally, but usually with
new (Linux) features: The record shipped with the RTL doesn't
correctly map the memory structure, thus making you read a byte
remaining zero. I had to redeclare TMSQid_ds using
/usr/include/x86_64-linux-gnu/bits/msq.h as the blueprint:Code: Pascal
 [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i        
TMSQid_ds = record                /// \brief structure describing
operation permission                msg_perm: TIPC_perm;             
 /// \brief time of last msgsnd command                msg_stime:
time_t;                {$ifndef CPUX86_64}                       
glibc_reserved0: culong;                {$endif}                ///
\brief time of last msgrcv command                msg_rtime: time_t; 
             {$ifndef CPUX86_64}                       
glibc_reserved1: culong;                {$endif}                ///
\brief time of last change                msg_ctime: time_t;         
     {$ifndef CPUX86_64}                        glibc_reserved2:
culong;                {$endif}                /// \brief current
number of bytes on queue                msg_cbytes: msglen_t;        
      /// \brief number of messages currently on queue               
msg_qnum: msgqnum_t;                /// \brief max number of bytes
allowed on queue                msg_qbytes: msglen_t;               
/// \brief pid of last msgsnd()                msg_lspid: pid_t;     
         /// \brief pid of last msgrcv()                msg_lrpid:
pid_t;                glibc_reserved3: culong;               
glibc_reserved4: culong;        end;for failing routines' return
values do a equal-comparisonyou can specify octal numbers by
prepending an ampersanduse sizeOf() where appropriate

----------------------------------------------------------------------
Thaddy · 2018-01-10 11:43

Quote from: Kays on January 10, 2018, 12:32:24 pm[Yeah, this happens
occasionally, but usually with new (Linux) features: The record
shipped with the RTL doesn't correctly map the memory structure
So you did not know to add {$packrecords C} ??

----------------------------------------------------------------------
Kays · 2018-01-10 12:10

Quote from: Thaddy on January 10, 2018, 12:43:37 pm[…] So you did not
know to add {$packrecords C} ?? […]Nah, I wasn't particularly aware of
that now. I don't compile my RTL, though. I use what's packaged.

So I first headed to /usr/share/fpcsrc/3.0.0/packages/rtl-
extra/src/ipc.pp and then looked at bits/msq.h for reference. As the
fields aren't already in order, I assumed that's the problem.

And there's a {$packrecords C} in ipc.pp; I can't tell right off the
bat whether it has/had its proper effect, but I guess the peeps who
write RTL units know what they're doing.

PS: “the fields aren't already in order”: I've had another look onto
I: I mean the fields msg_first and msg_last don't appear in my
bits/msq.h, but they do in the if defined(Linux) branch in ipc.pp.
PPS: And this is already, at least in trunk, fixed. But, as I wrote, I
usually work/produce with already packaged (“stable”) stuff.

----------------------------------------------------------------------
eolandro · 2018-01-13 06:26

thanks so much!!!!

i was so much time stuck.