True, I should have mentioned that the mutex might have to span an entire
sequence of calls from open to close or something to that effect.
In the specific case of GD, it wouldn't actually be hard to make it
threadsafe. Shane did it before to GD1 and it should probably be done
again for our bundled version of GD2.
-Rasmus
On Tue, 21 Oct 2003, Andi Gutmans wrote:
> The question is if this is always enough. Say for example hypothetically
> that the GD library saves the state of the currently being manipulated
> graphic, it won't be enough to mutex its calls because there's some saved
> state in between the calls.
> I'm not sure there's a general way to deal with it. Sure you could have
> some general code for a mutex but I don't think that'll solve all of the
> problems.
>
> Andi
>
> At 02:06 AM 10/21/2003 +0200, Uwe Schindler wrote:
> >nice for that would be some macros (somewhere in zend????) which help in
> >the following way (the ext_skel should generate the code, too):
> >
> >a) define a global library identifier (for all blocks that should not run
> >at the same time)
> > zend_create_mutex(identifier)
> >
> >b) use some code like:
> > zend_start_synchronized(identifier) {
> > ...
> > ...
> > } zend_end_synchronized(identifier);
> >
> >(Same construct like zend_try). Without ZTS this macros should be empty...
> >
> >As I am the developer of the NSAPI SAPI (which runs only with ZTS) I would
> >like to have a GD extension where alle PHP_FUNCTIONs exported from there
> >should have such Java-like "synchronized" blocks.
> >
> >Uwe
> >
> >At 00:10 21.10.2003, you wrote:
> >>If the library you are wrapping is not threadsafe, one approach is to
> >>simply not worry about it and just mark your extension as not being safe
> >>to use in a threaded environment. The majority of people use PHP in a
> >>non-threaded environment anyway.
> >>
> >>If you want to be nice to the folks who do use PHP in a threaded
> >>environment, you can look into adding a semaphore lock around the calls
> >>into the code that is not threadsafe. Such a semaphore lock makes sure
> >>that only 1 thread at a time can enter the code. Other threads sit around
> >>and wait until it is their turn.
> >>
> >>-Rasmus
> >>
> >>On Mon, 20 Oct 2003, netcat wrote:
> >>
> >> > Hi, internals.
> >> >
> >> > Please send me (post here i mean) a few links about
> >> > 1. thread safety in general
> >> > 2. thread saftey in php
> >> > 3. I'm doing wrapper for librep wich is not thread
> >> > safe (so mailing archives say). Do I need to know
> >> > something special ?
> >> >
> >> >
> >> > After doing some googling i found thise for #1
> >> > http://www.unix.org/version2/whatsnew/threads.html
> >> > http://www.unix.org/version2/whatsnew/threadsref.html
> >> > is that a good reading ?
> >> >
> >> > any better suggestions for google requests than thise :
> >> > c thread safety -mail -archive -lists
> >> > c thread safety tutor
> >> > ?
> >> >
> >> > I couldn't find anything for #2 but it's not less
> >> > important than #1 :)
> >> >
> >> >
> >> >
> >>
> >>--
> >>PHP Internals - PHP Runtime Development Mailing List
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >-----
> >Uwe Schindler
> >[EMAIL PROTECTED] - http://www.php.net
> >NSAPI SAPI developer
> >Erlangen, Germany
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
