OK, I've modified my application to use wApp->bind() as shown below.
Unfortunately, if a session dies, my application still crashes, as before:
==================
terminate called after throwing an instance of 'Wt::WException'
what(): doRecursiveEventLoop(): session was killed
#5 0x00b3a183 in std::terminate() () from /usr/lib/libstdc++.so.6
#6 0x00b3a2c2 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x01767af8 in Wt::WebSession::doRecursiveEventLoop (
this=0xb5e3f850)
at /usr/local/src/wt-3.2.3/src/web/WebSession.C:1051
#8 0x0143a7da in Wt::WDialog::exec (this=0x87fedb8,
animation=...) at /usr/local/src/wt-3.2.3/src/Wt/WDialog.C:292
#9 0x08125562 in Login_GUI::confirm (this=0x87fed48,
message=..., info=..., id=..., passwd=..., name=...,
location=..., comment=...) at src/view/Login_GUI.cpp:75
#10 0x0816e002 in UIServer::showLogin (this=0x876aeb8,
message=..., info=...) at src/view/UIServer.cpp:716
#11 0x0816f107 in UIServer::processStatusEvent (this=0x876aeb8,
event=...) at src/view/UIServer.cpp:920
#12 0x0816f01c in UIServer::notifyStatusEvent (this=0x876aeb8)
at src/view/UIServer.cpp:913
#13 0x08150537 in boost::_mfi::mf0<void, UIServer>::operator() (
this=0x87fed10, p=0x876aeb8)
======================
Although the session was killed, the WServer::post() call still invokes the
callback, which eventually tries to post a WDialog.
Wt::WebSession::doRecursiveEventLoop sees the session is dead, and throws an
error.
What I don't understand is how this could happen. WServer::post() schedules a
call to
WebController::handleApplicationEvent(), which checks whether the session
corresponding to sessionID is alive before it invokes the session's callback.
On Nov 13, 2012, at 9:30 AM, Joseph VanAndel <vanan...@ucar.edu> wrote:
> Yes, although the logic is more complex, I can have the bound function
> callback into the shared object to retrieve the data that I wanted to pass to
> the bound function.
>
> For my application, I have a UIServer object (1 per session) and a
> StatusServer (singleton), which relays status messages between sessions.
> UIServer ctor calls
> StatusServer::connect( this,
> wApp->bind( boost::bind( &UIServer::notifyStatusEvent, this) ))
>
> StatusServer::postStatusEvent() will save a copy of the event in a
> per-session queue.
> and calls WServer::post(sessionid, callback), which indirectly calls
> UIServer::notifyStatusEvent()
>
> UIServer::notifyStatusEvent() calls
> StatusServer::getEvent() to retrieve the event, and call
> UIServer::processStatusEvent() to handle the StatusEvent.
>
>
> It would be quite helpful if <Wt_src>/examples/simplechat used
> WApplication::bind().
>
> I appreciate any examples, but examples that correctly handle real-world
> situations, like browser sessions being closed are MUCH more useful. As far
> as I can tell, because simplechat doesn't use WApplication::bind(), it may
> not safely handle browser sessions that are closed.
>
> If I get the chance, I'll submit a rewritten simplechat example that uses
> WApplication::bind(), but as they say "It won't be pretty!"
>
>
> On Nov 13, 2012, at 4:44 AM, Koen Deforche wrote:
>
>> Hey Joseph, Rob,
>>
>> I guess you are both indicating a limitation: WApplication::bind()
>> essentially returns a function without arguments, and thus all
>> arguments already have to be bound before the call, which makes it
>> useless when you want to pass on information from the external source.
>>
>> As a workaround, perhaps you can rather than 'push' new information,
>> make the bound function 'poll' the information from the shared object
>> ?
>>
>> I believe it should be possible to make WApplication::bind() work
>> properly with any kind of function, including functions with free
>> parameters -- although that requires a bit of digging into the
>> meta-function possiblities of boost-ified c++...
>>
>> In any case, using WApplication::bind() later on is not very useful --
>> it needs to happen with the session lock and with the objects bound
>> guaranteed to be alive at the moment of calling WApplication::bind().
>>
>> Regards,
>> koen
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> witty-interest mailing list
>> witty-interest@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
