[fpc-devel] Fpsigprocmask

Marco van de Voort marcov at stack.nl
Tue Jan 26 14:47:22 CET 2010

In our previous episode, Michael Schnell said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 01/26/2010 01:18 PM, Marco van de Voort wrote:
> > 1) syncobjs
> >   
> OK for me, if the developers here don't discourage this, as they
> discourage using libc.pp

As Jonas (and the libc_unit link I posted earlier) clearly stated, they use 
LIBRARY libc, not UNIT libc.
> (see up in this thread:
> >>> On 01/20/2010 02:12 PM, Michael Van Canneyt wrote:
> >>>>> You should not use it.
> )
> > 2) if it _has_ to be libc free, unit ipc
> >   
> For me it has not to be  libc-free, but Michel, what is your opinion ?


> I don't know the ipc unit. I'll take a look.
> I suppose IPC is "Inter Process Communication" so supposedly it's not
> perfectly suited for inter Thread communication (see FUTEX vs. MUTEX)

IPC is a class of functions. If futex was a portable concept and would
become POSIX, it would probably all under the IPC class.

> > 3) explain here why the above two are not good enough.
> >   
> I'd like to
> (1) do the code according to what the RTL developers say is the
> recommended way 

Use as portable units as possible, until you have proven that there is
either something wrong with them, or a measurable performance problem in
your app.

> (2) use the most suited algorithm (thus FUTEX) in the most agreeable way
> (the one I know is via PThreadLib that AFAIK is done within libc

There is also pthreads, but afaik it also mostly contains portable calls.

> but maybe the RTL implements something else and the developers recommend
> this for the long run).

If the whole world uses mutexes, except some highspeed devices in the
kernel, what are you doing that this is really needed? IMHO you are high on
a concept, and haven't really researched if you really need it.

More information about the fpc-devel mailing list