Re: Reworked qt terminal is much faster – and fails to work on Mac

[Yuriy K. <yu...@gm...>]

Daniel J Sebald wrote:
> On 02/13/2014 05:09 AM, Yuriy Kaminskiy wrote:
>> sfeam wrote:
>>> On Wednesday, 12 February 2014 08:50:18 PM Daniel J Sebald wrote:
>>>> On 02/12/2014 02:49 PM, Thomas Bleher wrote:
>>>>> * Daniel J Sebald<dan...@ie...>   [2014-02-12 06:36]:
[...]
>>>> Local event loop might work, but that seems like a lot of overhead to
>>>> communicate every time with a remote program with any sort of high
>>>> bandwidth.  Local event loops are what dialog boxes can and often use.
>>>> Overhead isn't an issue there.
>>> I don't agree that an event loop is needed for this particular purpose.
>>> We don't have a case of asynchronous processes sending each other
>>> signals at random times.  We just want some way for the daughter
>>> process to signal back to the parent process "I'm ready now, you can
>>> proceed".   And we want some way for the parent to wait for this
>>> signal without burning CPU cycles.   One would think from its name that
>>> QLocalSocket::waitForConnected() provides exactly this service, but
>>> evidently it doesn't.    At least in linux it should be possible to have the
>>> parent call sigwait(), and the daughter call kill(parent_pid, SIGUSR1).
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> No need to involve Qt in this.
>> Signals is *increadibly* fragile IPC mechanism. There are very hard restriction
>> on what is permitted in signal handlers (that frequently violated, which result
>> in very hard-to-catch and nasty bugs), you can easily end up with racy code,
>> signals may lost, etc.
> 
> I've not experienced such a thing and found, so far, Qt signals/slots 
> fairly robust.  Mutexes seem to work rather well for across thread 

I refer here to "asynchronous signals" - see `man 7 signal` and `man 2
sigaction`, `man 3 sigwait`, `man 2 kill`, etc, *not* to Qt's signals/slots (I
don't think they are anyhow related; besides, Qt signals are not "IPC mechanism").

> traffic.  Do you have an example of a race condition?  I can't think of 
> any hard and fast rules other than one isn't supposed to cast the object 
> ID and use it as an object pointer because the object could be deleted. 
>   (Emitted signals are fine because any time an object is deleted, all 
> its connections are removed along with it.)
> 
> Within a thread there shouldn't be a race condition because signals are 
> processed right away, if I remember correctly.  Across thread are 
> treated differently.  They are queued.  But there is where the Mutex 
> comes into play.  By temporarily suspending a worker process (typically 
> on the order of milliseconds) and having the thread awoken when tasks 
> are complete, race conditions are avoided.