[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] call-backs, co-routines and inversion of control

On 08.01.2013, at 10:52, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:

> On Tue, Jan 8, 2013 at 12:59 AM, Miguel Negrao
> <miguel.negrao-lists@xxxxxxxxxxxxxxxxx> wrote:
>> A 06/01/2013, às 22:37, Julian Rohrhuber escreveu:
>>> I still have those commits sitting around which would arguably make a good first step for a later more thorough implementation of this behaviour. I'd like to either push it or throw it away, because later on it will become useless - any suggestions? It currently mainly lacks an appropriately differentiated latency implementation (but this is the case with the current s.bind, too, so it doesn't take anything away.
>>> For reference, here is the patch.
>>> <bind_async.diff>
>> I think it would be a good idea to commit this, because it already allows to have completely automatic syncing for the end user. The only issue perhaps is that it will not keep the old behavior of the the bind method, since it will always sync on each async action, but from what I was told, all the async actions are run in sequence in the server anyway, so it doesn’t make much difference perhaps.
> But wouldn't that make a difference in the sclang context? If s.bind
> now always syncs at the end, and previously did not? One might want to
> send a bundle, do some langside stuff while the server is working, and
> only then wait on a sync.
> I haven't studied the code and don't know exactly what changes here,
> but if indeed the behavior of s.bind/makeBundle is changed in this
> regard, then I really think you should put it in a topic branch.

The changes are not very intrusive, because already now the implementation of s.bind is very reductive (i.e. ignores timing etc.).

> That
> way we can test it more, experiment with it and develop it without
> risk for introducing regressions in the master branch.

While this is certainly the correct procedure in principle, I don't think that many of us would actually use this branch. I am still not using branches myself, simply because I'm not in the position to keep track of them. I suppose it would just hang there and dry out.

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/