Does this effect only the C API's?

1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User

Welcome to IWETHEY!

Post #185,927 by ChrisR 12/3/04 12:29:40 PM Reply	Does this effect only the C API's? Seems like being able to mark things as threadsafe (or unsafe) would be the way to go.
Post #185,932 by FuManChu 12/3/04 12:46:46 PM Reply	It already does that for a good chunk of C code The GIL only locks the interpretation of Python bytecodes. So any C call can potentially release the GIL (and make that thread wait for the call to finish, at which point it reacquires the lock and proceeds). I/O is a pretty common use case for this. Note too, that each process has its own GIL.
Post #185,936 by admin 12/3/04 1:10:37 PM Reply	Not quite. The GIL locks the access of Python objects as well as the interpretation of the byte codes. So to do any real work with Python in C you still have to obtain the lock. It's basically cooperative multi-tasking. Additionally, if you create a thread in C, you have to set up a bunch of Python thread bookkeeping structures that will be used by the interpreter as well. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Python 2.4 final is out and has a new subprocess module - (FuManChu) - (8) - Dec. 2, 2004, 12:26:13 PM EST

Does it work with eudora2mbox.py? Yes, it does. Grr.... - (Another Scott) - Dec. 2, 2004, 05:12:42 PM EST

They need to get rid of the global interpreter lock -NT - (admin) - (6) - Dec. 2, 2004, 01:00:41 PM EST

Feel free to submit a patch ;) -NT - (FuManChu) - (2) - Dec. 3, 2004, 12:24:30 PM EST

I don't need to. - (admin) - (1) - Dec. 3, 2004, 01:11:33 PM EST

Multiprocess is indeed the way to go - (FuManChu) - Dec. 3, 2004, 01:41:58 PM EST

Does this effect only the C API's? - (ChrisR) - (2) - Dec. 3, 2004, 12:29:40 PM EST

It already does that for a good chunk of C code - (FuManChu) - (1) - Dec. 3, 2004, 12:46:46 PM EST

Not quite. - (admin) - Dec. 3, 2004, 01:10:37 PM EST

Everyone sing a song about popcorn!
34 ms