remove support for seq mode read for extract etc.

see comment in sequential

We used to not stall if the read position was zero, ie. if the first
request was for a line some way down the image, and assume this was
extract or somesuch. But this could sometimes break on busy, many-core
systems.

Think of a better way to support eg.  extract safely in sequential mode.
This commit is contained in:
John Cupitt 2014-02-25 12:28:36 +00:00
parent 4d85011a51
commit 594af28c8e
6 changed files with 17 additions and 13 deletions

View File

@ -1,5 +1,6 @@
24/2/14 started 7.38.5
- jpeg load from buffer could write to input, thanks Lovell
- remove support for seq mode read for operations like extract
13/2/14 started 7.38.4
- --sharpen=none option to vipsthumbnail was broken, thanks ferryfax

View File

@ -193,8 +193,6 @@ vips_extract_area_class_init( VipsExtractAreaClass *class )
vobject_class->description = _( "extract an area from an image" );
vobject_class->build = vips_extract_area_build;
operation_class->flags = VIPS_OPERATION_SEQUENTIAL_UNBUFFERED;
VIPS_ARG_IMAGE( class, "input", 0,
_( "Input" ),
_( "Input image" ),

View File

@ -470,8 +470,6 @@ vips_ifthenelse_class_init( VipsIfthenelseClass *class )
vobject_class->description = _( "ifthenelse an image" );
vobject_class->build = vips_ifthenelse_build;
operation_class->flags = VIPS_OPERATION_SEQUENTIAL_UNBUFFERED;
VIPS_ARG_IMAGE( class, "cond", -2,
_( "Condition" ),
_( "Condition input image" ),

View File

@ -354,8 +354,6 @@ vips_insert_class_init( VipsInsertClass *class )
vobject_class->description = _( "insert an image" );
vobject_class->build = vips_insert_build;
operation_class->flags = VIPS_OPERATION_SEQUENTIAL_UNBUFFERED;
VIPS_ARG_IMAGE( class, "main", -1,
_( "Main" ),
_( "Main input image" ),

View File

@ -228,8 +228,6 @@ vips_join_class_init( VipsJoinClass *class )
vobject_class->description = _( "join a pair of images" );
vobject_class->build = vips_join_build;
operation_class->flags = VIPS_OPERATION_SEQUENTIAL_UNBUFFERED;
VIPS_ARG_IMAGE( class, "in1", -1,
_( "in1" ),
_( "First input image" ),

View File

@ -16,6 +16,9 @@
* 4/9/12
* - stop all threads on error
* - don't stall forever, just delay ahead threads
* 25/2/14
* - we were allowing skipahead if the first request was for y>0, but
* this broke on some busy, many-core systems, see comment below
*/
/*
@ -144,11 +147,9 @@ vips_sequential_generate( VipsRegion *or,
return( -1 );
}
if( r->top > sequential->y_pos /* &&
sequential->y_pos > 0 */ ) {
/* We have started reading (y_pos > 0) and this request is for
* stuff beyond that, stall for a while to give other
* threads time to catch up.
if( r->top > sequential->y_pos ) {
/* This request is for stuff beyond the current read position,
* stall for a while to give other threads time to catch up.
*
* The stall can be cancelled by a signal on @ready.
*
@ -156,6 +157,16 @@ vips_sequential_generate( VipsRegion *or,
* deadlock, and we don't fail on timeout, since the timeout
* may be harmless.
*/
/* We used to not stall if the read position was zero, ie. if
* the first request was for a line some way down the image,
* and assume this was extract or somesuch. But this could
* sometimes break on busy, many-core systems.
*
* Think of a better way to support eg. extract safely in
* sequential mode.
*/
#ifdef HAVE_COND_INIT
gint64 time;