[PHP-DEV] request for thread safety advice

[Uwe Schindler]

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
> > [url]http://www.unix.org/version2/whatsnew/threads.html[/url]
> > [url]http://www.unix.org/version2/whatsnew/threadsref.html[/url]
> > 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: [url]http://www.php.net/unsub.php[/url]

-----
Uwe Schindler
[email]thetaphi@php.net[/email] - [url]http://www.php.net[/url]
NSAPI SAPI developer
Erlangen, Germany

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]

[Andi Gutmans]

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
>> > [url]http://www.unix.org/version2/whatsnew/threads.html[/url]
>> > [url]http://www.unix.org/version2/whatsnew/threadsref.html[/url]
>> > 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: [url]http://www.php.net/unsub.php[/url]

>
>-----
>Uwe Schindler
>thetaphi@php.net - [url]http://www.php.net[/url]
>NSAPI SAPI developer
>Erlangen, Germany
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]

[Rasmus Lerdorf]

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
> >> > [url]http://www.unix.org/version2/whatsnew/threads.html[/url]
> >> > [url]http://www.unix.org/version2/whatsnew/threadsref.html[/url]
> >> > 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: [url]http://www.php.net/unsub.php[/url]

> >
> >-----
> >Uwe Schindler
> >thetaphi@php.net - [url]http://www.php.net[/url]
> >NSAPI SAPI developer
> >Erlangen, Germany
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]

>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]

[Pierre-Alain Joye]

On Mon, 20 Oct 2003 17:35:30 -0700 (PDT)
Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> 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.

While working on my new gfx lib, I use these macros especially for FT2
and its cache and for the vectors graphics.

I did not deeply test and analyze external libs like png, tiff, and
others to see if they are really TS, but the most widely used seem to
be TS as there is not global static data. But I'm really not a thread
expert :-/

I'm interested in every issues you have got using GD2 (bundled) and how
you think to solve them (or how have you already solved them).

pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]

[netcat]

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
> [url]http://www.unix.org/version2/whatsnew/threads.html[/url]
> [url]http://www.unix.org/version2/whatsnew/threadsref.html[/url]
> 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 :)
>
>

Thanks for all the replies.
I will probably have more questions when i'll have
the time to continue working on the project.

--
NetCat



--------------------------------------------------------
FREE 10MB email + Antivirus + AntiSpam + POP3 + more....
Get it at [url]http://www.doal.co.il:81/free/?c=both[/url]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: [url]http://www.php.net/unsub.php[/url]