Small tweak in Message


#1

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.


#2

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


#3

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 !!!


#4

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


#5

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.


#6

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!


#7

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…


#8

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


#9

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


#10

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?


#11

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 ?


#12

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