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:
parent
4d85011a51
commit
594af28c8e
@ -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
|
||||
|
@ -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" ),
|
||||
|
@ -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" ),
|
||||
|
@ -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" ),
|
||||
|
@ -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" ),
|
||||
|
@ -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;
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user