Passing Objects

Started by JTaylor, March 13, 2015, 10:43:11 AM

Previous topic - Next topic

JTaylor

Is there a way to pass an object to another script?   May be silly question but thought I would ask.   Seems like it would lose its objectness.   Wasn't sure about pipes but figured the same would occur.

Also, would one be able to use C# Multi-threading within a WinBatch script?

Thanks.

Jim

td

In order, nope and not likely.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

Jim;

Curious - which particular objects? 

JTaylor

SocketHandle from sAccept().   At least I assume it is considered an Object. 

Jim

td

The 'SocketHandle' is as the name implies a handle.  A handle is generally an index into a table and it is unlikely though not impossible that the index would have the same meaning in separate processes.  It would depend to some extent on the underlying Windows socket implementation and/or luck.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

It should be noted that it is not all that  uncommon for system implemented handles to be usable across process.  The most common example being the window handle.   I don't believe that the WinSock extender obfuscates the handle in this case so the question of across process usability is dependent on the system implementation.   
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

And this means what?...in the context of passing this handle to another script?

Jim

td

Quote from: JTaylor on March 15, 2015, 06:18:26 PM
And this means what?...in the context of passing this handle to another script?

Assuming that by 'different script', you mean a script running in separate a process as opposed to a script executing via a WinBatch 'Call' statement then it means I don't know whether or not the handle will be valid in a different script.  The handle in question is provided by the system via the extender so its usefulness across processes depends on the system implementation and not the extender's.  It is the case that some system provided handles are usable across processes and some are not. The previously mentioned window handle being the most obvious example of the former that clearly shows that system handles are sometimes shared among processes.

You should be able to devise a couple of simple test scripts to determine whether or not socket handles as returned by the 'sAccept' function are valid across processes. 

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

Okay.  Doesn't appear to work but may just be me.  Not sure what you mean by "system implementation", that is, the way I configured something or the way Microsoft designed a particular version.  Oh well, figured it wasn't an option anyway.  Just thought I would ask as being able to process things faster would be useful.    Maybe you all will get around to implementing mulit-threading one day soon :-)

Jim

td

In the context of the sentence "The handle in question is provided by the system via the extender so its usefulness across processes depends on the system implementation and not the extender's", "system implementation" means the operating system's implementation of the underlying functionality vs. the extender implementation.    In other words, the operating system determines whether or not the handle is usable across processes and the extender does nothing to impact that usability one way or the other.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor