On Friday 26 May 2006 08:04, Jon Keating wrote:
> Yes, this sounds better. Just one thing is that the run() function in
> the plugins is not necessary for some plugins that will only use the
> callbacks. An example is the auto-reply plugin. The only thing it will
> do is run through the event loop. So, that means we have 2 different
> cases to comply with. Plugins that use other event loops (qt-gui,
> gtk-gui) and plugins that do not have an event loop.
I've been thinking some more about this, and come up with the following idea
on how it could be implemented:
CPlugin::run()
{
while (doRun)
{
if (hasPendingEvents())
processEvents();
else
// sleep, wait for a condition or do nothing i.e. busy wait
}
}
Plugins without an event loop (e.g. auto-reply) don't have to do anything
special. Qt-gui would create a class MyEventLoop inheriting from QEventLoop.
MyEventLoop::hasPendingEvents would be implemented like:
return CPlugin::hasPendingEvents() || QEventLoop::hasPendingEvents();
MyEventLoop::processEvents would be something similar. Then Qt-gui would
override CPlugin::run:
CQtGui::run()
{
MyEventLoop myloop;
QApplication app;
app.run();
}
Don't know how it would be done i gtk, but I'm assuming that it is possible in
some way.
> Currently, this hasn't been implemented, so we are just using the same
> thread as the daemon, which is not good. As you said, we need an event
> loop, which I think can be similar to how plugins were implemented in
> the old system, using a pipe to listen for signals.
What about, instead of using pipes, the daemon just appends events to the
plugin's event queue? This way plugins don't have to call
licqDaemon->PopPluginEvent(), they just process their own local queue. It
would make it fairly simple to implement asynchronous signals: the daemon
copies the event, appends it to the plugin's queue and continues with the
next callback. All callbacks that don't modify the event data could be async.
Of course, this could also be done with pipes and plugins poping events from
the daemon. But I think that would be a more complex solution (in the async
case at least).
> Well, we should not care about this. If a plugin is broken, what can we
> do? To impose a time limit would be impractical. What if the plugin
> really does need to use some time, such as an encryption plugin doing
> some long calculation. If the plugin hangs the daemon, the user will
> probably kill it before any sane time limit condition is imposed. So,
> I say, let the plugin developers fix it. In the meantime, user's
> don't have to run the plugin that is broken.
We could do something obscure like requiring that plugins always respond to
pings within a given timeframe. If they don't, the are restarted. But this is
proably overly complex, so I think you're right: let the plugin developers
fix it.
> > - sending signals plugin => daemon. Should the daemon poll plugins?
>
> What do you mean by this? Having the plugin push signals to the daemon?
> It can be done in the plugin's thread, the daemon will use mutexes, so
> it is thread-safe.
Yes, I realised this while trying to sleep. As you said, it's not a problem.
> > - other stuff...
One thing: shared_ptr isn't thread-safe. If they are supposed to be passed
between threads, some kind of wrapper has to be done.
// Erik
--
All programmers are optimists.
-- Frederick P. Brooks, Jr.
Erik Johansson
http://ejohansson.se
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Licq-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/licq-devel
