Thanks for you reply.
So if I understand correctly, actually WIX will create a process for each
custom action. However, I can't figure out why the http thread created in
the custom action doesn't exit when the process exit, it continues to
execute and leads to a crash when try to access heap memories in the
process.
Is there a way to resolve this?
Thanks!
Yun
On Sun, Feb 17, 2013 at 12:12 AM, Hoover, Jacob
<jacob.hoo...@greenheck.com>wrote:
> I believe this is caused by any .net ca being done in a separate stub
> process. Prior to .net 4, you could only have one version of the clr loaded
> during the life of the process. The wix fix which allows us to overcome
> this is using child stub processes and ipc to overcome this.
>
>
> On Feb 16, 2013, at 7:26 AM, "Yun Li" <nic...@gmail.com> wrote:
>
> Hi, WIX Devs
>
> Thanks for such a great tool!
>
> I have a problem developing my own installers with Wix.
> I defined several custom actions in a DLL, these functions share a same
> behavior that they need to send the instrumentation data to our server
> through HTTP request.
> When WIX calls a custom action, as my observation, it starts a new thread
> for the function, and the thread exits after the function is returned.
> However, the problem is when the thread exits, *the heap storage created
> in the custom action thread is also removed*! Which leads to a crash when
> HTTP callback thread tries to access the objects created in the heap.
> What described above is only my observation, I just want to confirm
> whether this is really the memory management method of thread adopted by
> WIX (something like ThreadLocal, if I understand correctly), therefore we
> can think about other ways for solution.
>
> Thanks,
> Yun
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
>
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
