I think I found a regression with _thread in micropython 1.20 -> 1.23 [PICO W]

[GM-Script-Writer-62850]

EDIT:
#16008
Seems calling ntptime.setTime() while _thread is running makes everything break in 1.23
Made some code to replicate the issue

import _thread
import ntptime
import asyncio
import aiohttp
import time

sleep=asyncio.sleep_ms
ntptime.host="10.0.0.69"
wlan = 0

def _thread_work():
	while 1:
		then=time.ticks_ms()
		time.sleep(1)
		then=time.ticks_diff(time.ticks_ms(),then)
		print("Core 1:",then)

async def wifi():
	from wifi_auth import ssid, password
	import network

	global wlan
	wlan = network.WLAN(network.STA_IF)
	wlan.active(True)
	wlan.config(pm = 0xa11140)# Power management is very very bad, ping time is around 1000x worse and packet loss insane
	wlan.connect(ssid, password)

	while 1:
		while 1:
			wstat=wlan.status()
			if wstat < 0 or wstat >= 3:
				break
			print('Waiting for WiFi connection...')
			await sleep(1000)

		if wlan.status() == 3:
			status = wlan.ifconfig()
			print('Wifi Connected; ip =',status[0])
			while wlan.isconnected():
				await sleep(30000)
			print('WiFi Down')
		else:
			print("Failed to connect to wifi; retry in 30 seconds")
			await sleep(30000)
		wlan.connect(ssid, password)
#END wifi()

async def setTime():
	#ntptime.settime() failure: [Errno 110] ETIMEDOUT
	#ntptime.settime() failure: overflow converting long int to machine word
	print('Attempt to set time')
	success=0
	try:
		ntptime.settime()
		success=1
	except OverflowError:
		# it is not going to work
		print("overflow error; settime is borked")
	except OSError:
		print("ntptime.settime() failure")
	if not success:
		await sleep(10000)
		asyncio.create_task(setTime())
#END setTime()

async def wait4clock():
	delay=2000
	while time.time() < 1640995200: # Wait for clock to set or a 1 year...)
		print("Waiting for clock...")
		await sleep(3000)
	print('Clock set:',time.time())
#END wait4clock()

async def main():
	asyncio.create_task(wait4clock())
	asyncio.create_task(wifi())
	while not wlan or not wlan.isconnected():
		await sleep(1000)
	asyncio.create_task(setTime())
	while 1:
		then=time.ticks_ms()
		await sleep(1000)
		then=time.ticks_diff(time.ticks_ms(),then)
		print("Core 0:",then)

_thread.start_new_thread(_thread_work,())

asyncio.run(main())

output:

Waiting for clock...
Waiting for WiFi connection...
Core 1: 1000
Waiting for WiFi connection...
Core 1: 1000
Waiting for WiFi connection...
Core 1: 1000
Waiting for clock...
Wifi Connected; ip = 10.0.0.190
Core 1: 1000
Attempt to set time
Core 1: 1492
Core 0: 1489
Core 1: 3532
Clock set: 1728874072
Core 0: 3533
Core 1: 1792
Core 0: 1790
Core 1: 24677
Core 0: 24677
Core 1: 5324
Core 0: 5324
Core 1: 24677
Core 0: 24678
Core 1: 5329
Core 0: 5329
Core 1: 24673
Core 0: 24674
Core 1: 5324
Core 0: 5324
Core 1: 3173
Core 0: 3173
Core 1: 21506
Core 0: 21506
Core 1: 5324
Core 0: 5324
Core 1: 24677
Core 0: 24677
Core 1: 5325
Core 0: 5325
Core 1: 24689
Core 0: 24689
Core 1: 5319
Core 0: 5319
Core 1: 24674
Core 0: 24674
Core 1: 5324
Core 0: 5325
Core 1: 15870
Core 0: 15870
Core 1: 8807
Core 0: 8807
Core 1: 5325
Core 0: 5325
Core 1: 12901
Core 0: 12901

---

ORIGINAL POST: While my W5500 PICOs are working great and i can actually use dual cores without random crashes, my PICO W in another story

so i was working on one of my PICO Ws, now updated with 1.3 running a new version of my code when suddenly my code was 'freezing' but could get unstuck, well after fixing a few dozen bugs in my untested code i got everything fixed and had it running, unconnected from my laptop and connect it to it's own power and i turn around and it froze.
out of time i just disabled my second thread leaving a feature broken w/ no idea how it was breaking anything

so i get some more time to work on it today fixed some more bugs and try to debug this freezing issue i find the line it is freezing on, then it starts freezing in a completely different area of the code (different asycio loop)

note that one of my bug i had when this was happening was the second core was sleeping for 1000x longer than expected, but core 2 was testing 2 GPIO input pins, finding 2 false values and sleeping for a very long time, but how can that make core 1 freeze?

well after fixing so many bugs in my code i found all unrelated to the issue i deiced to revert back to micropython 1.2 and guess what no longer happens...

When this happens it happens seconds after power on
When the pico powers up it starts a few uasyncio serveries, get wifi up, get clock set, get main process started, get the web GUI running

Anyone have a known issue for this? some simple code to trigger it? i know NOBODY is going to look at over 1000 lines of my code and hook up a D18B20 and max7219 to try to find this issue, but if you want to prove me wrong

note that now that i am using a max7219 instead of driving panels directly i could just use a single core, but i hate to waste a core when i could use it and make it feel super responsive regardless of what is happening

Note, this freeze happens around 50% of the time
Also noticed the stop button works in Thonny w/ micropython 1.2 but not 1.3 when using 2 cores

[peterhinch]

I suggest changing Ctrl_switch to a coroutine and ignoring the second core, at least as a test. Sharing data between the two cores requires considerable know-how because the GIL is not used. See this doc for an explanation of the issues.

[peterhinch]

if it did that there would not be a freeze

I therefore take it that the object of the exercise is to learn about multi-core MicroPython? In which case I do urge you to read the doc I cited. The absence of the GIL means that communication between the cores requires considerable know-how.

not sure if it is save to run uasyncio.create_task from core 1 when uasyncio us running on core 0

That is a train wreck - the pairing heap in asyncio is not thread safe. This is the essence of the problem: to communicate between the cores you need thread-safe structures and these are rare.

[GM-Script-Writer-62850]

i think i found a possible issue, lines 208 - 213 of main.py, a possible un-closed connection where the NIC has a limit of 4 connections

was making change to use aiohttp when i noticed this

[GM-Script-Writer-62850]

that was not the issue, it seems to not be freezing at all, it is as if time self is running at order of magnate slower than it should

both core are affected and time.sleep_ms(500) takes closer to 10 seconds then 0.5s

[GM-Script-Writer-62850]

this looks to go south when the clock gets set
this is what _thread is working on:

	while 1:
		then=time.ticks_ms()
		time.sleep(1)
		then=time.ticks_diff(time.ticks_ms(),then)
		print("Core 1:",then)

this starts off giving 1000/1001
then ntptime.settime() does it thing and all of a sudden things so silly
i get 1036,1520,1695,5349,24643,5360,24640,5321,24681,5319 wait a minute or two and it settles down and work as expected

[peterhinch]

If an asyncio script changes the system time then things will go to rats. The asyncio scheduler relies on machine time to schedule tasks.