Re: [sc-dev] Remote server crash

[Scott Wilson <i@xxxxxxxxxxxxxx>]

Yes, I must confess I also thought that this was something that had been 'maintained' into a broken state, whereas it worked before. Without necessarily commenting on this particular case, as I don't know Tim's reasons, I think one can make reasonable objections to making changes to working code simply to have it use more 'modern' libraries, languages, etc.

That said, I don't know about these race conditions he refers to. It's also pretty obvious that a switch to Qt5 is probably a question of when rather than if.

IAC, I can try your patch tomorrow Dan, thanks!

S.

On 30 Oct 2013, at 20:57, Dan Stowell <danstowell+sc3@xxxxxxxxx> wrote:

> At this point I would like to point out the MASSIVE IRONY: Tim is
> being sarcastic about people being scared of all his code changes,
> when in this case it's one of his code changes that caused a severe
> bug. Maybe Tim will notice that irony one day.
> 
> Scott, would you be able to try this patch?
> 
> Dan
> 
> 
> 2013/10/30 Scott Wilson <s.d.wilson@xxxxxxxxxx>:
>> Tim's reply below. I guess it means that change could probably be reverted.
>> 
>> S.
>> 
>> Begin forwarded message:
>> 
>> From: Tim Blechmann <tim@xxxxxxxxxx>
>> Subject: Re: [sc-dev] Remote server crash
>> Date: 30 October 2013 12:38:31 GMT
>> To: Scott Wilson <s.d.wilson@xxxxxxxxxx>
>> 
>> [...]
>> 369 scsynth                             0x0000000101c76bbd
>> operator==(ReplyAddress const&, ReplyAddress const&) + 29
>> (SC_Reply.cpp:30)
>> 370 scsynth                             0x0000000101c76bbd
>> operator==(ReplyAddress const&, ReplyAddress const&) + 29
>> (SC_Reply.cpp:30)
>> 371 scsynth                             0x0000000101c76bbd
>> operator==(ReplyAddress const&, ReplyAddress const&) + 29
>> (SC_Reply.cpp:30)
>> 372 scsynth                             0x0000000101c76bbd
>> operator==(ReplyAddress const&, ReplyAddress const&) + 29
>> (SC_Reply.cpp:30)
>> 3
>> [...]
>> 
>> 
>> What I don't understand is how this code, in SC_Reply.cpp, could ever
>> be anything other than an infinite loop:
>> 
>> 
>> Copying Tim, as he seems to be the last person to touch that code.
>> 
>> 
>> can probably just be removed ... it would be best to rewrite most of the
>> io code with boost.asio, including networking, timers, serial, midi, hid
>> to get rid of all the nasty race conditions, but well ... people will
>> just complain that they don't understand the code, the full blast of
>> 'just in case' arguments and the like ...
>> 
>> whatever, sc is not dead, it just smells funny ...
>> 
>> tim, who will soon get into qt5-land but without sc :/
>> 
>> 
> 
> 
> 
> -- 
> http://www.mcld.co.uk
> <ReplyEquals.diff.txt>


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/