[erlang-questions] Difference between ei.a and ei_st.a?

[Zabrane Mickael]

Hi guys,

$ ls -la /usr/lib/erlang/lib/erl_interface-3.7.7/lib/
total 3352
drwxr-xr-x 6 root wheel 204 11 jui 17:59 .
drwxr-xr-x 6 root wheel 204 11 jui 17:15 ..
-rw-r--r-- 1 root wheel 611488 11 jui 17:59 libei.a
-rw-r--r-- 1 root wheel 599240 11 jui 17:59 libei_st.a
-rw-r--r-- 1 root wheel 247816 11 jui 17:59 liberl_interface.a
-rw-r--r-- 1 root wheel 247000 11 jui 17:59 liberl_interface_st.a


Why there's 2 libei*.a?
Which one should I link to when building my linked-in driver (or NIF)?

N.B: same for Windows, there's: ei.lib and ei_md.lib (and even ei_mdd.lib) !!!

Regards,
Zabrane

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Björn-Egil Dahlberg]

Hi,

ST is not thread safe. You get only libei_st.a if configure can't find a suitable thread library.

Both are built when a thread library is found.

On a side note. Are you sure you want to use erl_interface in a NIF or a linked-in driver?

Erl_Interface is useful when creating c-nodes and talking distribution to erlang nodes otherwise, not so much.

I know there are examples where ei is used in linked-in drivers and I think they are misleading.

// Björn-Egil

2012/9/2 Zabrane Mickael <zabr...@gmail.com>

[Zabrane Mickael]

Hi Björn,

> ST is not thread safe. You get only libei_st.a if configure can't find a suitable thread library.
> Both are built when a thread library is found.

Ok I see. So the best is to link with "libei.a" which is threa safe (and avoid "ibei_st.a"), right?

Does the same apply for windows? Should I link with "ei.lib" instead of "ei_md.lib"?

> On a side note. Are you sure you want to use erl_interface in a NIF or a linked-in driver?

No no, it was just an example.

[Björn-Egil Dahlberg]

On 2012-09-03 06:27, Zabrane Mickael wrote:
> Hi Björn,
>
>> ST is not thread safe. You get only libei_st.a if configure can't find a suitable thread library.
>> Both are built when a thread library is found.
> Ok I see. So the best is to link with "libei.a" which is threa safe (and avoid "ibei_st.a"), right?
>
> Does the same apply for windows? Should I link with "ei.lib" instead of "ei_md.lib"?

MD = multithreaded dynamic
MDD = multithreaded dynamic with debug symbols

(Became unsure and have to look it up =)

Note also that in the non-windows case the name can change meaning.

If thread lib detected
libei_st = not thread safe (single threaded)
libei = thread safe

if no thread lib is detected
libei = not thread safe (single threaded)

I'm unsure if this is a wise convention. Probably just to be able to say
"link with libei.a and liberl_interface.a" regardless.

This can all be seen in lib/erl_interface/src/Makefile.in

// egil

[Zabrane Mickael]

1000x thanks Egil.

Regards,
Zabrane

[Per Hedeland]

Björn-Egil Dahlberg <eg...@erlang.org> wrote:
>
>Note also that in the non-windows case the name can change meaning.
>
>If thread lib detected
>libei_st = not thread safe (single threaded)
>libei = thread safe
>
>if no thread lib is detected
>libei = not thread safe (single threaded)

(and ditto for liberl_interface). Thanks, I was just about to point this
out, since we got bitten by the silent build of a non-thread-safe
version called liberl_interface.a (on QNX...).

>I'm unsure if this is a wise convention. Probably just to be able to say
>"link with libei.a and liberl_interface.a" regardless.

Right, who wants to link with an unsafe version.:-) It makes superficial
sense, but is a really bad idea if you need to build for many different
OSes and don't dig deeply into the configure/Makefile logic when it just
"seems to work", nor specifically test thread-safeness of the result
(may not be simple).

What I did - besides teaching lib/erl_interface/configure.in to look for
pthreads support in libc (where it can be found on QNX) - was a minor
tweak such that this configure *fails* if you pass --enable-threads and
no pthreads support can be found (and then made sure to pass this option
in our builds, of course). Unfortunately I never got around to offer
those changes back to OTP, and as reward I now find that they were lost
in one of our OTP upgrades.:-( (I still have the original ones of
course.)

--Per