On Wed, 3 Jan 2007 06:51:57 +0100
"Wojciech Malota" <[EMAIL PROTECTED]> wrote:
> > How would your code decide when to actually go ahead and remove the
> > semaphore?
> >
> > Are you suggesting that the semaphore simply be removed whenever it
> > is determined to be "unlocked"? Meaning you want to
> How would your code decide when to actually go ahead and remove the
> semaphore?
>
> Are you suggesting that the semaphore simply be removed whenever it
> is determined to be "unlocked"? Meaning you want to call semget() and
> semctl(IPC_RMID) for every single lock/unlock?
I've wrote about it in
On Wed, 3 Jan 2007 01:20:41 +0100
"Wojciech Malota" <[EMAIL PROTECTED]> wrote:
> > So the point is that you cannot remove the semaphore when there are no
> > callers waiting in semop because that is a perfectly valid state.
>
> Yes, but if function which acquires a semaphore is constructed as
>
> So the point is that you cannot remove the semaphore when there are no
> callers waiting in semop because that is a perfectly valid state.
Yes, but if function which acquires a semaphore is constructed as
my_sem_acquire function it will be safe to remove the semaphore when it is
released (if s
> Yes, but no hosters do that and I would actually push for turning this
> very usefull extension on by default. I spoke with Ilia before and we
> can most likely even bundle it when we make the library file in memory
> as well. And I think we should improve the ext a bit and put it in.
It seems c
On Tue, 2 Jan 2007 20:04:19 +0100
"Wojciech Malota" <[EMAIL PROTECTED]> wrote:
> > I don't understand. If your "FIFO" is some kind of refcount that won't
> > work because the refcount would not be shared by multiple separate
> > PHP processes. You would have to put the refcount in shared memory
>
> I don't understand. If your "FIFO" is some kind of refcount that won't
> work because the refcount would not be shared by multiple separate
> PHP processes. You would have to put the refcount in shared memory
> and even then there's no guarantee that the semaphore will be cleaned
> up properly be
On Tue, 2 Jan 2007 08:35:10 +0100
"Wojciech Malota" <[EMAIL PROTECTED]> wrote:
> It's impossible to correct remove semaphores with sem_remove function
> when I use them to provide execution of concurrent processes.
> When the last process releases the semaphore I should be able to remove
> it. But
Derick Rethans wrote:
> On Tue, 2 Jan 2007, Kevin Waterson wrote:
>
> > This one time, at band camp, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> >
> > > Also, to repeat myself here, there is also no way to use filepro
> > > database, hwapi, msession, cpdf, dio, fam, ingres, mnogosearch, yp
> > >
Hello,
On 1/2/07, Jonas Smedegaard <[EMAIL PROTECTED]> wrote:
Help developing libGD, coordinating it with the official packaging of the
library for Debian.
I confirm this request. Can someone open this account please? I will
take care of the karma, thanks.
--Pierre
--
PHP Internals - PHP Ru
On Tue, 2 Jan 2007, Kevin Waterson wrote:
> This one time, at band camp, Antony Dovgal <[EMAIL PROTECTED]> wrote:
>
> > Also, to repeat myself here, there is also no way to use filepro database,
> > hwapi, msession,
> > cpdf, dio, fam, ingres, mnogosearch, yp API, Ovrimos, PayFlow Pro and a
> >
On Sun, 31 Dec 2006, Antony Dovgal wrote:
> When we move something to PECL or deprecate a core extension in favor of its
> PECL analogue, it does not mean the PECL extension should be moved into core,
> that's not the point.
> Btw, quite a number of useful extensions were born in PECL and there ar
Kevin Waterson wrote:
> This one time, at band camp, Antony Dovgal <[EMAIL PROTECTED]> wrote:
>
>> Also, to repeat myself here, there is also no way to use filepro database,
>> hwapi, msession,
>> cpdf, dio, fam, ingres, mnogosearch, yp API, Ovrimos, PayFlow Pro and a
>> bunch of other functions
Hello,
On 1/2/07, Kevin Waterson <[EMAIL PROTECTED]> wrote:
I appreciate your point about not having everything available to core. The
extensions you
mention above are very specific to a task, where-as validating a file mimetype
is quite a
generic procedure. To this end I would like to see mo
bbgdjgkdjggfdggdf and more info
D
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
This one time, at band camp, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> Also, to repeat myself here, there is also no way to use filepro database,
> hwapi, msession,
> cpdf, dio, fam, ingres, mnogosearch, yp API, Ovrimos, PayFlow Pro and a bunch
> of other functions
> without using PECL.
I app
Hi Antony,
Antony Dovgal wrote:
> On 12/31/2006 02:43 AM, Kevin Waterson wrote:
>>> While mime_magic is deprecated, it does not mean it cannot be used.
>>> So there certainly is a way to do it without PECL.
>> Currently, but it will be moved sometime in the future.
>>
>>> Anyone capable of install
Help developing libGD, coordinating it with the official packaging of the
library for Debian.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
18 matches
Mail list logo
