Nп/п : 23 из 100
 От   : Peter Ebden                         2:5075/128        26 сен 23 14:20:58
 К    : All                                                   26 сен 23 05:07:02
 Тема : The GIL and PyEval_RestoreThread
----------------------------------------------------------------------------------
                                                                                 
@MSGID:
<mailman.347.1695780179.23016.python-list@python.org> e968d2cf
@REPLY:
<CAJANk5Ezbnadnp8Kg-yafCB3SOfrrgHwbsPBqEkzDrArWrOyEQ@mail.gmail.com> 9419b3c1
@REPLYADDR Peter Ebden <peter@thoughtmachine.net>
@REPLYTO 2:5075/128 Peter Ebden
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<mailman.347.1695780179.23016.python-list@python.org>
@RFC-References:
<CAJANk5Ezbnadnp8Kg-yafCB3SOfrrgHwbsPBqEkzDrArWrOyEQ@mail.gmail.com>
@TZUTC: 0100
@TID: FIDOGATE-5.12-ge4e8b94
Hi all,

I`ve been working on embedding Python and have an interesting case around
locking with PyEval RestoreThread which wasn`t quite doing what I expect,
hoping someone can explain what I should expect here.

I have a little example (I`m running this in parallel from two different
threads; I have some more C code for that but I don`t think it`s super
interesting):

void run python(PyThreadState* thread) {
  LOG("Restoring thread %p...", thread);
  PyEval RestoreThread(thread);
  LOG("Restored thread %p", thread);
  PyRun SimpleString("import time; print(`sleeping`); time.sleep(3.0)");
  LOG("Saving thread...");
  PyThreadState* saved thread = PyEval SaveThread();
  LOG("Saved thread %p", saved thread);
}

This produces output like
11:46:48.110058893: Restoring thread 0xabc480...
11:46:48.110121656: Restored thread 0xabc480
11:46:48.110166060: Restoring thread 0xabc480...
sleeping
11:46:48.110464194: Restored thread 0xabc480
sleeping
11:46:51.111307541: Saving thread...
11:46:51.111361075: Saved thread 0xabc480
11:46:51.113116633: Saving thread...
11:46:51.113177605: Saved thread 0xabc480

The thing that surprises me is that both threads seem to be able to pass
PyEval RestoreThread before either reaches the corresponding
PyEval SaveThread call, which I wasn`t expecting to happen; I assumed that
since RestoreThread acquires the GIL, that thread state would remain locked
until it`s released.

I understand that the system occasionally switches threads, which I guess
might well happen with that time.sleep() call, but I wasn`t expecting the
same thread to become usable somewhere else. Maybe I am just confusing
things by approaching the same Python thread from multiple OS threads
concurrently and should be managing my own locking around that?

Thanks in advance,

Peter

-- 
Thought Machine Group Limited, a company registered in England & Wales.
Registered number: 11114277. 
Registered Office: 5 New Street Square, 
London EC4A 3TW 
rce=g>.


The content of this email is confidential and intended for the recipient 
specified in message only. It is strictly forbidden to share any part of 
this message with any third party, without a written consent of the sender. 
If you received this message by mistake, please reply to this message and 
follow with its deletion, so that we can ensure such a mistake does not 
occur in the future.
--- FIDOGATE 5.12-ge4e8b94
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 50/109 301/1 467/888 4500/1 5000/111
5001/100 5005/49 5020/715 830
SEEN-BY: 5020/848 1042 4441 12000 5030/49 1081
5054/8 5061/133 5075/128
SEEN-BY: 5080/102 5083/1 444
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх