Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2010-01

mlockall() unit libc

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Stefan Kisdaroczi

hi all,

i need the mlockall() call (unit libc) in my realtime apps on linux i386 to lock the address space of the process. Works, but unit libc has no future and it's the only function i need from this unit.

I would like to add this call to another unit (unix? baseunix?). Can I look at the fpmmap() implementation or are there better "examples" ? Thanks for any hints.

kisda

Reply by email

Marco van de Voort
to Stefan Kisdaroczi

In our previous episode, Stefan Kisdaroczi said:

i need the mlockall() call (unit libc) in my realtime apps on linux i386 to lock the address space of the process. Works, but unit libc has no future and it's the only function i need from this unit.

mlockall is part of the posix 2001 realtime extensions, which are afaik optional. And usually it only works for root.

IOW not all Unices might implement it, which is more or less the rule of thumb to get into one of the portalbe units (unix,baseunix)

Sometimes exceptions to this rule are made (e.g. for UUID functions) when the function are found to be implemented on all unix platforms.

I checked and they (+ the corresponding unlock) are in FreeBSD5+, so FreeBSD is no problem (MCL_CURRENT and MCL_FUTURE are the mandatory flags by Posix, and FreeBSD only supports those)

I saw some hints on the web that OS X doesn't support it (but it should be checked against 10.3/10.4+ since afaik those implement a lot more calls due to synchronization with FreeBSD5)

Then solaris and Haiku as the other unices must be checked.

Reply by email

Jonas Maebe
to Marco van de Voort
Marco van de Voort wrote 5 lines
I saw some hints on the web that OS X doesn't support it (but it should be checked against 10.3/10.4+ since afaik those implement a lot more calls due to synchronization with FreeBSD5)
$ gcc -o mlockall mlockall.c

$ ./mlockall
mlockall:1: Function not implemented
munlockall:1: Function not implemented
mlockall:2: Function not implemented
mlockall:3: Function not implemented

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.8
BuildVersion: 9L31a

(that's the mlockall test program from http://www.oit.uci.edu/dcslib/digital_unix/digital-v40d/APS33DTE/DOCU_005.HTM)

Then solaris and Haiku as the other unices must be checked.

Solaris at least has man pages for those functions. The test program fails there too, but that's probably simply because I'm not root (the man page says that root permissions are required).

Jonas

Reply by email

Marco van de Voort
to Jonas Maebe

In our previous episode, Jonas Maebe said:

Show quoted text 13 lines
> I saw some hints on the web that OS X doesn't support it (but it > should be > checked against 10.3/10.4+ since afaik those implement a lot more > calls due > to synchronization with FreeBSD5) $ gcc -o mlockall mlockall.c $ ./mlockall mlockall:1: Function not implemented munlockall:1: Function not implemented mlockall:2: Function not implemented mlockall:3: Function not implemented

Hmm, in that case I'll actually try to run this program on FreeBSD with root tonight.

But, to summarize then chances for generic units are slim. The unportable garbage "linux" unit is then the only solution, and then hope that cut down linuxes don't cut it out.

> Then solaris and Haiku as the other unices must be checked. Solaris at least has man pages for those functions. The test program fails there too, but that's probably simply because I'm not root (the man page says that root permissions are required).

If such a recent Darwin doesn't have it, then IMHO it is not an option now.

Reply by email