Can we get to see vasslthreads.h?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Can we get to see vasslthreads.h?

Louis LaBrunda
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Seth Berman
Hi Lou,

The function getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Seth Berman
Follow up,

A smart guy reminded me getpid() could also be a macro from a standards point of view, which means you might not be able to call it at all on certain systems or versions.

-- Seth

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
In reply to this post by Seth Berman
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Seth Berman
Hi Lou

System osProcessId

-- Seth

On Sunday, September 9, 2018 at 2:30:28 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
Thanks Seth,

That's even better.

Lou

On Sunday, September 9, 2018 at 3:43:05 PM UTC-4, Seth Berman wrote:
Hi Lou

System osProcessId

-- Seth

On Sunday, September 9, 2018 at 2:30:28 PM UTC-4, Louis LaBrunda wrote:
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Andres Valloud-5
In reply to this post by Louis LaBrunda
Hello,

The function getpid() is governed by POSIX, and virtually all POSIX functions can also be a macro:


This means that, even if there is a function called 'getpid', you still do not know (and you are not even supposed to know) if there is a macro called 'getpid' that does something like this:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

Therefore, if it's one of those functions that POSIX says is allowed to be a macro (i.e., any of them), that function should never be called via FFI at all because the behavior isn't guaranteed to be what you would get from a C compiler.  If you call such functions anyway, you're asking for strange "VM bugs" nobody can diagnose and that later on get papered over as "compiler bugs", or "kernel bugs", or "heisenbugs", etc.  The reality is that using an FFI like that is asking for undefined behavior, as in "anything and everything becomes possible".

I'm not saying there are no compiler or kernel bugs --- but if those do exist and are affecting your program, the number one requirement to file a bug against those programs is following the relevant documentation to the letter.  Spec lawyering is not always fun, but I care that my program works and that carries me over the occasional annoyance.

The picture changes on a per platform basis, and one has to be aware of these things.  On Windows, for instance, it's a different story --- in there, usually when MSDN says 'there is a function called foo() that...', it really means there is an actual function called foo() visible to the users, and so you can call that via an FFI.  Be aware, however, that once you do that then all the rules of C apply to your program.  For the sake of illustration, Windows API calls change behavior depending on which thread is calling them.  This is just one example out of an exceedingly large list.

In summary, using an FFI to call C programs turns you into a C programmer regardless of whether you happen to be notating such usage in Smalltalk.

Andres.


On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda <[hidden email]> wrote:
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
Hi Andres,

Thanks for the information and the explanation.  It is always helpful to see the big picture.  I expect Seth's recommendation to use "System osProcessId" means the VM has obtained the PID in the proper manner and we can feel safe using it to get the PID.

Lou


On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
Hello,

The function getpid() is governed by POSIX, and virtually all POSIX functions can also be a macro:

<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html

This means that, even if there is a function called 'getpid', you still do not know (and you are not even supposed to know) if there is a macro called 'getpid' that does something like this:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

Therefore, if it's one of those functions that POSIX says is allowed to be a macro (i.e., any of them), that function should never be called via FFI at all because the behavior isn't guaranteed to be what you would get from a C compiler.  If you call such functions anyway, you're asking for strange "VM bugs" nobody can diagnose and that later on get papered over as "compiler bugs", or "kernel bugs", or "heisenbugs", etc.  The reality is that using an FFI like that is asking for undefined behavior, as in "anything and everything becomes possible".

I'm not saying there are no compiler or kernel bugs --- but if those do exist and are affecting your program, the number one requirement to file a bug against those programs is following the relevant documentation to the letter.  Spec lawyering is not always fun, but I care that my program works and that carries me over the occasional annoyance.

The picture changes on a per platform basis, and one has to be aware of these things.  On Windows, for instance, it's a different story --- in there, usually when MSDN says 'there is a function called foo() that...', it really means there is an actual function called foo() visible to the users, and so you can call that via an FFI.  Be aware, however, that once you do that then all the rules of C apply to your program.  For the sake of illustration, Windows API calls change behavior depending on which thread is calling them.  This is just one example out of an exceedingly large list.

In summary, using an FFI to call C programs turns you into a C programmer regardless of whether you happen to be notating such usage in Smalltalk.

Andres.


On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Mariano Martinez Peck-2


On Mon, Sep 10, 2018 at 6:32 PM Louis LaBrunda <[hidden email]> wrote:
Hi Andres,

Thanks for the information and the explanation.  It is always helpful to see the big picture.  I expect Seth's recommendation to use "System osProcessId" means the VM has obtained the PID in the proper manner and we can feel safe using it to get the PID.


Hi Lou,

Yes, I personally think #osProcessId is safer because it ends up calling a VM primitive. This is NOT a FFI call. 
 
Cheers,


Lou


On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
Hello,

The function getpid() is governed by POSIX, and virtually all POSIX functions can also be a macro:


This means that, even if there is a function called 'getpid', you still do not know (and you are not even supposed to know) if there is a macro called 'getpid' that does something like this:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

Therefore, if it's one of those functions that POSIX says is allowed to be a macro (i.e., any of them), that function should never be called via FFI at all because the behavior isn't guaranteed to be what you would get from a C compiler.  If you call such functions anyway, you're asking for strange "VM bugs" nobody can diagnose and that later on get papered over as "compiler bugs", or "kernel bugs", or "heisenbugs", etc.  The reality is that using an FFI like that is asking for undefined behavior, as in "anything and everything becomes possible".

I'm not saying there are no compiler or kernel bugs --- but if those do exist and are affecting your program, the number one requirement to file a bug against those programs is following the relevant documentation to the letter.  Spec lawyering is not always fun, but I care that my program works and that carries me over the occasional annoyance.

The picture changes on a per platform basis, and one has to be aware of these things.  On Windows, for instance, it's a different story --- in there, usually when MSDN says 'there is a function called foo() that...', it really means there is an actual function called foo() visible to the users, and so you can call that via an FFI.  Be aware, however, that once you do that then all the rules of C apply to your program.  For the sake of illustration, Windows API calls change behavior depending on which thread is calling them.  This is just one example out of an exceedingly large list.

In summary, using an FFI to call C programs turns you into a C programmer regardless of whether you happen to be notating such usage in Smalltalk.

Andres.


On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda <[hidden email]> wrote:
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
Hi Mariano,

I agree.  When I was looking for a solution to getting the PID, I missed "System osProcessId".  I think I had seen getpid() somewhere and figured there would be someway to call it and get the PID.  When I found it and it worked, I stopped there.  I certainly prefer "System osProcessId" over making a platform function and calling it.

Lou


On Tuesday, September 11, 2018 at 8:15:14 AM UTC-4, marianopeck wrote:


On Mon, Sep 10, 2018 at 6:32 PM Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:
Hi Andres,

Thanks for the information and the explanation.  It is always helpful to see the big picture.  I expect Seth's recommendation to use "System osProcessId" means the VM has obtained the PID in the proper manner and we can feel safe using it to get the PID.


Hi Lou,

Yes, I personally think #osProcessId is safer because it ends up calling a VM primitive. This is NOT a FFI call. 
 
Cheers,


Lou


On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
Hello,

The function getpid() is governed by POSIX, and virtually all POSIX functions can also be a macro:

<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html

This means that, even if there is a function called 'getpid', you still do not know (and you are not even supposed to know) if there is a macro called 'getpid' that does something like this:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

Therefore, if it's one of those functions that POSIX says is allowed to be a macro (i.e., any of them), that function should never be called via FFI at all because the behavior isn't guaranteed to be what you would get from a C compiler.  If you call such functions anyway, you're asking for strange "VM bugs" nobody can diagnose and that later on get papered over as "compiler bugs", or "kernel bugs", or "heisenbugs", etc.  The reality is that using an FFI like that is asking for undefined behavior, as in "anything and everything becomes possible".

I'm not saying there are no compiler or kernel bugs --- but if those do exist and are affecting your program, the number one requirement to file a bug against those programs is following the relevant documentation to the letter.  Spec lawyering is not always fun, but I care that my program works and that carries me over the occasional annoyance.

The picture changes on a per platform basis, and one has to be aware of these things.  On Windows, for instance, it's a different story --- in there, usually when MSDN says 'there is a function called foo() that...', it really means there is an actual function called foo() visible to the users, and so you can call that via an FFI.  Be aware, however, that once you do that then all the rules of C apply to your program.  For the sake of illustration, Windows API calls change behavior depending on which thread is calling them.  This is just one example out of an exceedingly large list.

In summary, using an FFI to call C programs turns you into a C programmer regardless of whether you happen to be notating such usage in Smalltalk.

Andres.


On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda <[hidden email]> wrote:
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mp...@...

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
In reply to this post by Andres Valloud-5
Hi Andres,

I have been thinking about your post and while I believe what you say is true I wonder why it is true, meaning why would things be built that way?  This is not a criticism of anything you have said and I expect your advice is sound.  I'm just wondering why things are the way they are.  My knowledge in this area is very old, much of it predates the invention of C.  So, I may use terms that don't quite match the modern definitions.

Lets say we have a program, a library and a function, defined in and supported by the library.  Back in the old days of computing, not so far back that there weren't operating systems but very far back, a library could either be compiled as part of a program or separately.  If separately, the OS needed to be involved with linking and binding and loading in order for a program to get to and use a function.  If compiled together, there was less of that.  There were also macros.  A macro was a group of instructions, its use allowed a programmer to write one line of code instead of many but there wasn't any magic that turned a function into a macro.  Back when memory was costly (I worked on an early IBM mainframe that had 1 MB of ram and a second MB cost half a million dollars) programmers had to decide to use functions because they took up less memory or macros because the were faster.

I can image one of todays compilers being smart enough to look at a function definition and decide to automatically (maybe governed by options) make it a macro and in-line the code in the program that calls the function.  Even if this is the case, I don't see why the library can't be compiled separately and linked with the function in it in a way that the function is externalized and can be called by programs via the OS.  If this is the case and even if a function has been compiled in a program as a macro, the program should be able to call a function of the same name via the OS and get the function to run in the library.

I don't know how this works with C and on modern computers but I would expect that there is an opcode (hardware based) that tells the OS that it wants something special done (the OS would define what and how that works) this would be how programs get external functions run.  I don't see the program needing to know anything more about the library and function than names and what needs to be passed back and forth.  The fact the the same function has been turned into a macro in the program shouldn't matter.

Maybe I am way off in terms of how I imagine things can work, if so, that's the way it goes.  But if not and things are exactly as you say, than that would be a shame.

Lou



On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
Hello,

The function getpid() is governed by POSIX, and virtually all POSIX functions can also be a macro:

<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html

This means that, even if there is a function called 'getpid', you still do not know (and you are not even supposed to know) if there is a macro called 'getpid' that does something like this:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

Therefore, if it's one of those functions that POSIX says is allowed to be a macro (i.e., any of them), that function should never be called via FFI at all because the behavior isn't guaranteed to be what you would get from a C compiler.  If you call such functions anyway, you're asking for strange "VM bugs" nobody can diagnose and that later on get papered over as "compiler bugs", or "kernel bugs", or "heisenbugs", etc.  The reality is that using an FFI like that is asking for undefined behavior, as in "anything and everything becomes possible".

I'm not saying there are no compiler or kernel bugs --- but if those do exist and are affecting your program, the number one requirement to file a bug against those programs is following the relevant documentation to the letter.  Spec lawyering is not always fun, but I care that my program works and that carries me over the occasional annoyance.

The picture changes on a per platform basis, and one has to be aware of these things.  On Windows, for instance, it's a different story --- in there, usually when MSDN says 'there is a function called foo() that...', it really means there is an actual function called foo() visible to the users, and so you can call that via an FFI.  Be aware, however, that once you do that then all the rules of C apply to your program.  For the sake of illustration, Windows API calls change behavior depending on which thread is calling them.  This is just one example out of an exceedingly large list.

In summary, using an FFI to call C programs turns you into a C programmer regardless of whether you happen to be notating such usage in Smalltalk.

Andres.


On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:
Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:
Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.
vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.
Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call
(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:
Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Andres Valloud-5
In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to [hidden email] <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at https://groups.google.com/group/va-smalltalk
>         <https://groups.google.com/group/va-smalltalk>.
>         For more options, visit https://groups.google.com/d/optout
>         <https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email]
> <mailto:[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:[hidden email]>.
> Visit this group at https://groups.google.com/group/va-smalltalk.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
Hi Andres,

I understand that things are the way they are and I guess that there are rules to follow.  But I don't understand why someone couldn't compile a library as an external library like an so or DLL with the functions defined with external linkage and then be called by other programs.

Lou

On Tuesday, September 11, 2018 at 12:56:55 PM UTC-4, Andres Valloud wrote:
In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     <a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <<a href="http://man7.org/linux/man-pages/man2/getpid.2.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to va-smalltalk...@googlegroups.com <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk
>         <<a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk>.
>         For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout
>         <<a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com
> <mailto:<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk+unsubscribe@...>.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@...
> <mailto:<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@googlegroups.com>.
> Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Andres Valloud-5
I'd be more interested in "why wouldn't they".

On Tue, Sep 11, 2018, 19:45 Louis LaBrunda <[hidden email]> wrote:
Hi Andres,

I understand that things are the way they are and I guess that there are rules to follow.  But I don't understand why someone couldn't compile a library as an external library like an so or DLL with the functions defined with external linkage and then be called by other programs.

Lou

On Tuesday, September 11, 2018 at 12:56:55 PM UTC-4, Andres Valloud wrote:
In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to [hidden email] <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at https://groups.google.com/group/va-smalltalk
>         <https://groups.google.com/group/va-smalltalk>.
>         For more options, visit https://groups.google.com/d/optout
>         <https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email]
> <mailto:[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:[hidden email]>.
> Visit this group at https://groups.google.com/group/va-smalltalk.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
Hi,

On Tuesday, September 11, 2018 at 4:56:46 PM UTC-4, Andres Valloud wrote:
I'd be more interested in "why wouldn't they".

I'm always interested in "why" things are the way they are.  In an earlier post you gave some example code:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

have you ever actually seen code like this in a library?  I have a hard time imagining why anyone would write code like it.  If one doesn't want a function to work, just leave it out of the library.  An error will be returned and that's it.  Why write a booby trap?

Lou

 
On Tue, Sep 11, 2018, 19:45 Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="CpE8WJz3BwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:
Hi Andres,

I understand that things are the way they are and I guess that there are rules to follow.  But I don't understand why someone couldn't compile a library as an external library like an so or DLL with the functions defined with external linkage and then be called by other programs.

Lou

On Tuesday, September 11, 2018 at 12:56:55 PM UTC-4, Andres Valloud wrote:
In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     <a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <<a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to va-smalltalk...@googlegroups.com <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk
>         <<a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk>.
>         For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout
>         <<a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to va-smalltalk...@googlegroups.com
> <mailto:va-smalltalk+[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:va-sma...@googlegroups.com>.
> Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
> For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="CpE8WJz3BwAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="CpE8WJz3BwAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Andres Valloud-5
You see it as a booby trap because the way that code is designed does not support the non standard usage that you want.

The same code can also be seen as a feature of modularity and backwards compatibility targeting the intended majority audience who use the code as per the manual.

That you cannot imagine why does not prove it's wrong.

It's no use arguing to be more correct than the authors.  POSIX just does not work that way.

IIRC, in some versions of AIX, there is no memset() function visible to an FFI.

On Wed, Sep 12, 2018, 14:59 Louis LaBrunda <[hidden email]> wrote:
Hi,

On Tuesday, September 11, 2018 at 4:56:46 PM UTC-4, Andres Valloud wrote:
I'd be more interested in "why wouldn't they".

I'm always interested in "why" things are the way they are.  In an earlier post you gave some example code:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

have you ever actually seen code like this in a library?  I have a hard time imagining why anyone would write code like it.  If one doesn't want a function to work, just leave it out of the library.  An error will be returned and that's it.  Why write a booby trap?

Lou

 
On Tue, Sep 11, 2018, 19:45 Louis LaBrunda <[hidden email]> wrote:
Hi Andres,

I understand that things are the way they are and I guess that there are rules to follow.  But I don't understand why someone couldn't compile a library as an external library like an so or DLL with the functions defined with external linkage and then be called by other programs.

Lou

On Tuesday, September 11, 2018 at 12:56:55 PM UTC-4, Andres Valloud wrote:
In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to [hidden email] <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at https://groups.google.com/group/va-smalltalk
>         <https://groups.google.com/group/va-smalltalk>.
>         For more options, visit https://groups.google.com/d/optout
>         <https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email]
> <mailto:[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:[hidden email]>.
> Visit this group at https://groups.google.com/group/va-smalltalk.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Louis LaBrunda
Andres, can you please supply a link to somewhere that says and explains why calling a POSIX function, in a library, that may have been compiled somewhere as a macro is a problem or against the rules.

Thanks in advance.

Lou


On Wednesday, September 12, 2018 at 9:14:01 AM UTC-4, Andres Valloud wrote:
You see it as a booby trap because the way that code is designed does not support the non standard usage that you want.

The same code can also be seen as a feature of modularity and backwards compatibility targeting the intended majority audience who use the code as per the manual.

That you cannot imagine why does not prove it's wrong.

It's no use arguing to be more correct than the authors.  POSIX just does not work that way.

IIRC, in some versions of AIX, there is no memset() function visible to an FFI.

On Wed, Sep 12, 2018, 14:59 Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="zGRaRPAsCAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:
Hi,

On Tuesday, September 11, 2018 at 4:56:46 PM UTC-4, Andres Valloud wrote:
I'd be more interested in "why wouldn't they".

I'm always interested in "why" things are the way they are.  In an earlier post you gave some example code:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

have you ever actually seen code like this in a library?  I have a hard time imagining why anyone would write code like it.  If one doesn't want a function to work, just leave it out of the library.  An error will be returned and that's it.  Why write a booby trap?

Lou

 
On Tue, Sep 11, 2018, 19:45 Louis LaBrunda <[hidden email]> wrote:
Hi Andres,

I understand that things are the way they are and I guess that there are rules to follow.  But I don't understand why someone couldn't compile a library as an external library like an so or DLL with the functions defined with external linkage and then be called by other programs.

Lou

On Tuesday, September 11, 2018 at 12:56:55 PM UTC-4, Andres Valloud wrote:
In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     <a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <<a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to va-smalltalk...@googlegroups.com <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk
>         <<a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk>.
>         For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout
>         <<a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to va-smalltalk...@googlegroups.com
> <mailto:va-smalltalk+[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:va-sma...@googlegroups.com>.
> Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
> For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="zGRaRPAsCAAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="zGRaRPAsCAAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Can we get to see vasslthreads.h?

Andres Valloud-5
Why, yes --- appendix D of the VisualWorks DLLCC user guide.  Unfortunately I do not have a URL handy for that.

On Thu, Sep 13, 2018 at 5:54 AM, Louis LaBrunda <[hidden email]> wrote:
Andres, can you please supply a link to somewhere that says and explains why calling a POSIX function, in a library, that may have been compiled somewhere as a macro is a problem or against the rules.

Thanks in advance.

Lou


On Wednesday, September 12, 2018 at 9:14:01 AM UTC-4, Andres Valloud wrote:
You see it as a booby trap because the way that code is designed does not support the non standard usage that you want.

The same code can also be seen as a feature of modularity and backwards compatibility targeting the intended majority audience who use the code as per the manual.

That you cannot imagine why does not prove it's wrong.

It's no use arguing to be more correct than the authors.  POSIX just does not work that way.

IIRC, in some versions of AIX, there is no memset() function visible to an FFI.

On Wed, Sep 12, 2018, 14:59 Louis LaBrunda <[hidden email]> wrote:
Hi,

On Tuesday, September 11, 2018 at 4:56:46 PM UTC-4, Andres Valloud wrote:
I'd be more interested in "why wouldn't they".

I'm always interested in "why" things are the way they are.  In an earlier post you gave some example code:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

have you ever actually seen code like this in a library?  I have a hard time imagining why anyone would write code like it.  If one doesn't want a function to work, just leave it out of the library.  An error will be returned and that's it.  Why write a booby trap?

Lou

 
On Tue, Sep 11, 2018, 19:45 Louis LaBrunda <[hidden email]> wrote:
Hi Andres,

I understand that things are the way they are and I guess that there are rules to follow.  But I don't understand why someone couldn't compile a library as an external library like an so or DLL with the functions defined with external linkage and then be called by other programs.

Lou

On Tuesday, September 11, 2018 at 12:56:55 PM UTC-4, Andres Valloud wrote:
In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to [hidden email]om <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at https://groups.google.com/group/va-smalltalk
>         <https://groups.google.com/group/va-smalltalk>.
>         For more options, visit https://groups.google.com/d/optout
>         <https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email]om
> <mailto:va-smalltalk+unsubscri[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:va-sma...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/va-smalltalk.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]om.
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.