urequests and _thread: (Pico W) issue

[flori8029]

Dear users,

currently, I'm developing a program that uses both urequests and _thread on my Pico W with micropython (v1.24.1). Everything works fine until I uncomment the line _thread.start_new_thread(blinken, ()) which should start a function on the other core that does nothing but printing "Hello" periodically.

import urequests, network, time, _thread

def blinken():
    while True:
        print("Hello")
        time.sleep_ms(10 * 1000)

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('xxx', 'yyy')

#_thread.start_new_thread(blinken, ())

while True:
    print("Rstart")
    request = urequests.get('http://example.com/test.php', auth=('xxx' , 'yyy'))
    content = request.text
    time.sleep_ms(1)
    print("Rend")
    request.close()
    time.sleep_ms(30 * 1000)

When I uncomment the mentioned line and restart the program the following error occurs (already in the first iteration of the while-True-Loop that contains the request):

Traceback (most recent call last):
  File "<stdin>", line 16, in <module>
  File "requests/__init__.py", line 201, in get
  File "requests/__init__.py", line 94, in request
OSError: [Errno 103] ECONNABORTED

I should mention that the urequest.get() needs about 10 seconds to get its data from the server (that's normal because the server needs some time to assemble this data; the received size of the received data doesn't cause any memory overflow).
I already did some research and tried using the timeout option in get, but that didn't work. The network connection is stable. I couldn't find out any reasons for that behavior. That's why I would be glad if you could assist me solving this issue.

Yours sincerely,
flori8029

[scruss]

_thread is highly experimental and best avoided. Maybe try a timer for recurring tasks.

[mendenm]

does this behave differently if you wait for the network to come all the way up before starting your second thread? I use something like:

nic.connect(net[0], netdict[netname])
while nic.status() > network.STAT_IDLE and nic.status() != network.STAT_GOT_IP: 
     time.sleep(1) #check again later

I haven't used urequests directly, but I have had code running using microdot and the second thread which works/worked fine (or at least it used to, in older version of micropython. I haven't used this code for more than a year, so an update might have broken it).

[scruss]

no, it can still crash whenever. There's no memory protection, so if you're used to threads being well-behaved on machines with operating systems, MicroPython's is quite the wrench.

[mendenm]

@scruss If no one experiments with _thread, it will remain experimental forever! :-)

My experience was that I had (essentially) unlimited uptime (months at a time), but I only used the second thread for reading and reducing data from the ADC, not for any i/o through external software stacks. All calls to system functions were from the main thread.

I do have recent, non-networked threaded code which also apparently runs indefinitely without crashes. See:

https://github.com/mendenm/rp2_micropython_tricks/tree/main/blinky_lights

which is a sample application of my DMA/PIO-based WS2812/neopixel driver.