It already does that for a good chunk of C code

IWETHEY v. 0.3.0 | TODO

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

Welcome to IWETHEY!

Post #185,932

by FuManChu

12/3/04 12:46:46 PM

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

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

iwethey.org

It's hard to be religious when certain people are never incinerated by bolts of lightning.
42 ms