Update modules to be Lua coroutine compatible

[TerryE]

Changes as per #846. I still have to do fill testing. I can do the net, uart and wifi ones. COAP is pretty moribund anyway at the moment. This is more to provoke feedback comment than to merge just yet.

[pjsg]

As a matter of interest, why is the GC disabled here for a short time? I don't think that it needs to be..... [Worse, if it does need to be disabled, then the disable call is probably missing from lots of other places as well]

[TerryE]

Don't know. I could take a look but I think that I'll leave this until we fix the net module properly.

[TerryE]

These seem to be stable. Anyone found any probs?

[dnc40085]

@TerryE I'm pretty sure that the conflicts are caused by #1018, which includes the lua coroutine compatibility fix for wifi.c.

[TerryE]

@dnc40085 @jmattsson @devsaurus @pjsg, you are the guys who have worked on these stacks in the past. This PR has been sitting here for 3 weeks. I am assuming that no one has any issues other than the merge conflicts created by later PRs that have been accepted as dnc40085 mentions. If I don't hear to the contrary in the next day or so, then I'll remove these conflicts and merge this PR myself.

[TerryE]

As a matter of interest, why is the GC disabled here [in net_socket_disconnect] for a short time? I don't think that it needs to be.

@pjsg Philip, it's a cludge, and it's used in a couple of other places in the module. The net.socket userdata include a self-reference via the registry, and this prevents GC of the userdata even if the socket isn't in scope anywhere in Lua. This can happen in circumstances like:

do
  local svr = net.createServer(net.TCP)
  srv:listen(888*,accept_cb)
end

Here without this reference, the GC could clean up the socket after exiting the do .. end and so it would have been freed by the time the accept_cb() fires. Unreferencing an entry in the Lua Registry can trigger an ECG run which will reclaim the userdata before the code is finished with it, hence this cludge. The correct Lua approach is to "turn out the lights when you leave the room", i.e. do the unregister last when the function doesn't need the userdata any more.

[jmattsson]

Happy to see this merged after conflicts resolved.

[TerryE]

Sorry guys, I am now on a Greek Island and my only access is by logging on from my local Taverna.

I have also been fire-fighting an issue with a forum where I am an active contributor and it's gone belly-up because the sole-owner decided to take his ball and go home (shut it down). With most of the mods and senior contributors, I am trying to do a phoenix -- the only prob is that I am the only experienced Sysdmin / PHP programmer / MySQL admin so it is sucking up all of my spare time for next week or so.

Juggling priorities and still trying to have a holiday.

[djphoenix]

Should I recreate this PR with resolved conflicts? Have merged to my repo successfully, all seems OK.

[pjsg]

@djphoenix -- yes, please restage and we can get this squared away....