wx_object locks

[Mazen Harake-2]

Hi all,

If I create a frame using wx_object, then using an event destroy the
frame and then start a new frame (wx_object or not doesn't matter I
think) then the new frame is not created before the process that runs
inside my callback function (specified with connect/3) returns from the
callback. I find this very odd... so I was wondering if this is intended
behaviour.

This code example (attached) shows what I'm trying to describe.
Instructions: do dlock:start(). then click on the middle of the frame
that appears. I expected this to destroy the frame that was open and
then create a new one but as long as the process in the callback is
alive it will not. To unlock the process and let it complete type the
following in the shell: pid(0,X,0) ! {continue}. where X is the Pid.
Then you should see that the first frame is removed and the second one
appears.

Is this intended?

Best regards,

/Mazen





________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

[Dan Gudmundsson]

Mazen Harake wrote:
> Hi all,
>
> If I create a frame using wx_object, then using an event destroy the
> frame and then start a new frame (wx_object or not doesn't matter I
> think) then the new frame is not created before the process that runs
> inside my callback function (specified with connect/3) returns from the
> callback. I find this very odd... so I was wondering if this is intended
> behaviour.

That is intended, callbacks from C++ to erlang are very tricky to get right.
wxWidgets is a single threaded application and doesn't expect a multithreaded
erlang above it. Which results in several deadlock sitatutions if not callbacks
are handled first. I have rewritten this part several times, this implementation
is the best so far. It get's tricky when you get recursive callbacks, i.e. you call
something from inside a callback which generates a new callback to erlang.

So use callbacks only when you really have to, and don't call any other erlang
wx process because then can get the deadlock up in erlang code, but at least that is
debug-able.

/Dan

>
> This code example (attached) shows what I'm trying to describe.
> Instructions: do dlock:start(). then click on the middle of the frame
> that appears. I expected this to destroy the frame that was open and
> then create a new one but as long as the process in the callback is
> alive it will not. To unlock the process and let it complete type the
> following in the shell: pid(0,X,0) ! {continue}. where X is the Pid.
> Then you should see that the first frame is removed and the second one
> appears.
>
> Is this intended?
>
> Best regards,
>
> /Mazen
>
>
>
> ------------------------------------------------------------------------
>
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org

________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org