Hi There.

I see from this message that you're working in the .NET bridge. I did a fair amount of work with this myself a year or two ago as a potential means to migrate some of our legacy VB6 stuff via COM interop so that we could use Squeak for our new software.

However, I had significant issues with load testing. When I started hitting the system with many processes the bridge would catastrophically fail due to limitations in the Windows TCP/IP stack: I'm sure you're aware that Windows has a built-in limit on the number of allowed open Sockets: I would quite easily hit this limit if I pushed hard enough, as the architecture of the bridge didn't clean up quickly enough for dead Squeak processes (this may really be a limitation in Squeak rather than the bridge, but the reliance on TCP/ IP communication between the two effectively means the same thing).

I had planned to try removing the use of sockets entirely and moving to something more scalable, but in the end the use case evaporated.

But I'd still love to know if you have progressed the bridge in a way that means you no longer get problems like the one I have described above. I'd also be willing to share any of the work I did in case it might help you, if I can find it.

Regards, Simon

On 25 Mar 2009, at 03:20, Aran Lunzer wrote:

Andreas wrote:

...

Aran Lunzer wrote:

...

Looking at the source code for the DLL, I'm afraid that at the level of my non-Squeak skills it would probably take me a day to rebuild it. Do you happen to have a 3.7-specific compiled DLL?

It is extremely unlikely that the problem is with the DLL. More likely you are switching between VMs that are not compatible with this version. Try running your 3.7 images with a more recent VM and see if this works with the DLL in question.

Back in my original message about OSProcess I mentioned that I'm working with a 3.7 Web-browser-plugin VM that has been customised (to do various things in support of the .NET bridge). If I can't persuade ProcessWrapper to work with that, I can't use it. At least, not this year :-)

I did a little more testing and, as you suggested, the more recent VM helped: the out-of-the-box 3.8 release (6665), for example, couldn't load the ProcessWrapper DLL with its standard VM (Nov 2003), but could when I wheeled in the VM from 3.9.

So it seems that something has changed in the VMs, and that something in the DLL only works with new ones. But given that Balasz said that they had used ProcessWrapper with 3.7, I wondered whether they had - or could recompile - a version of the DLL that would be compatible with an old VM.

What has changed in the VM wrt DLL loading? Something to do with 64/32-bit support, perhaps?

All the best -

Aran

Consider your responsibility to the environment - think before you print!

****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. *******************************************************************************************************************************************

Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA