Small tweak in Message

can be added an initializer for the messageRecipient in the Message class ? it seems i can’t generate a correct quitMessageId cause the MessageManager will check the messageRecipient to be zero, but i have no possibility to initialize it to 0 cause it is private.

Message::Message (const int intParameter1_,
                  const int intParameter2_,
                  const int intParameter3_,
                  void* const pointerParameter_) throw()
    : intParameter1 (intParameter1_),
      intParameter2 (intParameter2_),
      intParameter3 (intParameter3_),
      pointerParameter (pointerParameter_),
      messageRecipient (0)

thanx.

But it’s always set to 0 in MessageManager::postQuitMessage (?)…

yeah but postQuitMessage is private… so i have to manually create a quit message and send it with juce_postMessageOnSystemWhatever…

or (better) you make postQuitMessage public !!!

But you don’t have to call it directly - just use JUCEApplication::quit()!

well, in a linux juce vst plugin with the vst wrapper i have to exit from the shared message thread without killing the host. how could i do that ?

i noticed the shared message thread keeps hanging here (in calls of XNextEvent):

    void run()
    {
        MessageManager* const messageManager = MessageManager::getInstance();

        const int originalThreadId = messageManager->getCurrentMessageThread();
        messageManager->setCurrentMessageThread (getThreadId());

        while (! threadShouldExit()
               && ! messageManager->hasQuitMessageBeenPosted()
               && messageManager->dispatchNextMessage (false))         <<< here it blocks in XNextEvent
        {
        }

        messageManager->setCurrentMessageThread (originalThreadId);
    }

so i’m unable to check for threadShouldExit. even posting a quit message doesn’t help unblocking juce_dispatchNextMessageOnSystemQueue so i’ll get always a !! killing thread by force !! problem with crashes of the hosts.

any ideas ?

actually juce (on linux) is meant to be used as a standalone application only. its code is working with that in mind, but if you are trying to make a juce application live as a plugin of another app (and fully use its gui abilities) then you are a bit lost.

i’m trying to do my best to make this (vst with gui on linux for example) possible but:

  1. my patches to linux code seldom get accepted
  2. sometimes i feel a bit of filibustering when ask things in the internals of juce (i’m not speaking about not being able to show a Component in the screen)

i’m ranting here, deliberately… today i feel a bit frustrated.
i hope my words doesn’t get understood as wrong.

Is it blocking there because the code that’s trying to kill the message thread is actually running on the message thread?

And JUCEApplication::quit is static, so you should still be able to call it from a plugin, right?

[quote]
i’m trying to do my best to make this (vst with gui on linux for example) possible but:

  1. my patches to linux code seldom get accepted
  2. sometimes i feel a bit of filibustering when ask things in the internals of juce (i’m not speaking about not being able to show a Component in the screen)

i’m ranting here, deliberately… today i feel a bit frustrated.[/quote]

I totally understand - and I’m sorry! I’d love to have more time to spend on the linux stuff, but I’m just up to my eyeballs in win32/mac projects, so that’s where I have to devote all my time. It’s getting difficult to keep up with the volume of stuff that deserves to be added!

mmmh i don’t think so: the code that kills the message thread is runned in the VstWrapper destructor, and the destructor is called by the host thread in the dispatcher:

        if (activePlugins.size() == 0)
        {
#if JUCE_LINUX
            SharedMessageThread::deleteInstance();
#endif

            shutdownJuce_GUI();
        }

yeah sure, i can try it, but i can’t figure how that could differ.

I understand your time is limited, and you are focusing mainly on win-mac. but linux have its reason to be here too. i can help on the linux side, but sure i will need some more help from you to discovering the inner working of juce itself and to accept and valuate my patches; if not, i’m just wasting my time in a never ending trial and error path, useful only to me and not to others…

That could still be getting called by the message thread, though, couldn’t it?

mmmh the host can access our thread ? i don’t think so

Well, I’ve seen cases where the plugin makes an hostidle() call on its message thread, and the host uses the opportunity to call back into the plugin, so could that be happening?

yeah, if it’s like this, that could happen.
now i’ve started using JUCEApplication::quit instead of postQuitMessage and things seems better. is there any specific things you are doing in that function different than posting a quit message to the message thread ?

No, I think it just posts a message. Easy enough to have a look inside if you want to be certain.