Different environments in NIF API calls

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Different environments in NIF API calls

Harris, Robert
Hello,

I'm trying to understand the full implications of

"All API functions that read or write terms has the environment
that the term belongs to as the first function argument."

For example, can enif_get_map_value() be called with a map from
a process-bound environment and a key from a process-independent
one? If so, which environment would be used?

Similarly, does enif_compare require that its arguments share
the same environment?

Regards,

Robert

Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

Reply | Threaded
Open this post in threaded view
|

RE: Different environments in NIF API calls

Sverker Eriksson-4

The ‘env’ argument of functions that only read supplied terms (like enif_get_* functions) is not used in current implementation. And as we have introduced functions like enif_compare that lacks ‘env’ arguments, it is now impossible to do an implementation of the API where ERL_NIF_TERM’s are not self contained.

 

So, yes you can use enif_get_map_value with map and key argument from different environment. The same goes for enif_compare and all other functions with term arguments that are only read and not referred by new constructed terms.

 

/Sverker

 

 

From: erlang-questions <[hidden email]> On Behalf Of Harris, Robert
Sent: den 23 februari 2021 13:21
To: [hidden email] Questions <[hidden email]>
Subject: Different environments in NIF API calls

 

Hello,

I'm trying to understand the full implications of

"All API functions that read or write terms has the environment
that the term belongs to as the first function argument."

For example, can enif_get_map_value() be called with a map from
a process-bound environment and a key from a process-independent
one? If so, which environment would be used?

Similarly, does enif_compare require that its arguments share
the same environment?

Regards,

Robert

Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world.
To find out more, visit our website.


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Different environments in NIF API calls

Harris, Robert
Thank you for the reply.

Is it fair to assume that the value populated by enif_get_map_value()
will belong to the env of the map?

Regards,

Robert

> On 23 Feb 2021, at 17:56, Sverker Eriksson <[hidden email]> wrote:
>
> The ‘env’ argument of functions that only read supplied terms (like enif_get_* functions) is not used in current implementation. And as we have introduced functions like enif_compare that lacks ‘env’ arguments, it is now impossible to do an implementation of the API where ERL_NIF_TERM’s are not self contained.
>
> So, yes you can use enif_get_map_value with map and key argument from different environment. The same goes for enif_compare and all other functions with term arguments that are only read and not referred by new constructed terms.
>
> /Sverker
>
>
> From: erlang-questions <[hidden email]> On Behalf Of Harris, Robert
> Sent: den 23 februari 2021 13:21
> To: [hidden email] Questions <[hidden email]>
> Subject: Different environments in NIF API calls
>
> Hello,
>
> I'm trying to understand the full implications of
>
> "All API functions that read or write terms has the environment
> that the term belongs to as the first function argument."
>
> For example, can enif_get_map_value() be called with a map from
> a process-bound environment and a key from a process-independent
> one? If so, which environment would be used?
>
> Similarly, does enif_compare require that its arguments share
> the same environment?
>
> Regards,
>
> Robert
>
> Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
>
>
> Disclaimer
>
> The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
>
> This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
>

Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

Reply | Threaded
Open this post in threaded view
|

RE: Different environments in NIF API calls

Sverker Eriksson-4

Yes, all subterms of a compound term must belong to the same env as the top term.

 

/Sverker

 

From: Harris, Robert <[hidden email]>
Sent: den 23 februari 2021 19:14
To: Sverker Eriksson <[hidden email]>
Cc: [hidden email] Questions <[hidden email]>
Subject: Re: Different environments in NIF API calls

 

Thank you for the reply.

Is it fair to assume that the value populated by enif_get_map_value()
will belong to the env of the map?

Regards,

Robert


> On 23 Feb 2021, at 17:56, Sverker Eriksson <[hidden email]> wrote:
>
> The ‘env’ argument of functions that only read supplied terms (like enif_get_* functions) is not used in current implementation. And as we have introduced functions like enif_compare that lacks ‘env’ arguments, it is now impossible to do an implementation of the API where ERL_NIF_TERM’s are not self contained.
>
> So, yes you can use enif_get_map_value with map and key argument from different environment. The same goes for enif_compare and all other functions with term arguments that are only read and not referred by new constructed terms.
>
> /Sverker
>
>
> From: erlang-questions <[hidden email]> On Behalf Of Harris, Robert
> Sent: den 23 februari 2021 13:21
> To: [hidden email] Questions <[hidden email]>
> Subject: Different environments in NIF API calls
>
> Hello,
>
> I'm trying to understand the full implications of
>
> "All API functions that read or write terms has the environment
> that the term belongs to as the first function argument."
>
> For example, can enif_get_map_value() be called with a map from
> a process-bound environment and a key from a process-independent
> one? If so, which environment would be used?
>
> Similarly, does enif_compare require that its arguments share
> the same environment?
>
> Regards,
>
> Robert
>
> Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
>
>
> Disclaimer
>
> The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
>
> This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
>

Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Different environments in NIF API calls

Harris, Robert
Many thanks for the clarification, Sverker.

Regards,

Robert

> On 24 Feb 2021, at 09:56, Sverker Eriksson <[hidden email]> wrote:
>
> Yes, all subterms of a compound term must belong to the same env as the top term.
>
> /Sverker
>
> From: Harris, Robert <[hidden email]>
> Sent: den 23 februari 2021 19:14
> To: Sverker Eriksson <[hidden email]>
> Cc: [hidden email] Questions <[hidden email]>
> Subject: Re: Different environments in NIF API calls
>
> Thank you for the reply.
>
> Is it fair to assume that the value populated by enif_get_map_value()
> will belong to the env of the map?
>
> Regards,
>
> Robert
>
> > On 23 Feb 2021, at 17:56, Sverker Eriksson <[hidden email]> wrote:
> >
> > The ‘env’ argument of functions that only read supplied terms (like enif_get_* functions) is not used in current implementation. And as we have introduced functions like enif_compare that lacks ‘env’ arguments, it is now impossible to do an implementation of the API where ERL_NIF_TERM’s are not self contained.
> >
> > So, yes you can use enif_get_map_value with map and key argument from different environment. The same goes for enif_compare and all other functions with term arguments that are only read and not referred by new constructed terms.
> >
> > /Sverker
> >
> >
> > From: erlang-questions <[hidden email]> On Behalf Of Harris, Robert
> > Sent: den 23 februari 2021 13:21
> > To: [hidden email] Questions <[hidden email]>
> > Subject: Different environments in NIF API calls
> >
> > Hello,
> >
> > I'm trying to understand the full implications of
> >
> > "All API functions that read or write terms has the environment
> > that the term belongs to as the first function argument."
> >
> > For example, can enif_get_map_value() be called with a map from
> > a process-bound environment and a key from a process-independent
> > one? If so, which environment would be used?
> >
> > Similarly, does enif_compare require that its arguments share
> > the same environment?
> >
> > Regards,
> >
> > Robert
> >
> > Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
> >
> >
> > Disclaimer
> >
> > The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
> >
> > This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
> >
>
> Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
>
>
> Disclaimer
>
> The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
>
> This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
>

Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.